Subject: Re: [Last-Call] [I2nsf] Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16

From: Kyle Rose <[email-masked]>
Date: Wed, 2 Feb 2022 18:22:48 -0500

Apologies for the delay in responding, Paul. This addresses most of my
concerns. I note that some new redundancy has been introduced since -16,
notably for source-port/destination-port, which could be further
consolidated according to the DRY principle ("don't repeat yourself"). It's
probably worthwhile to scrub the entire ecosystem for this kind of
redundancy, but I wouldn't say it's a blocker.

Thanks,
Kyle

On Sat, Jan 22, 2022 at 8:55 AM Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> Hi Kyle and Tom,
> Here is the revision of I2NSF NSF-Facing Interface YANG Data Model Draft:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-17
>
> I attach a revision letter to explain how Patrick and I have addressed
> your comments.
>
> Thanks.
>
> Best Regards,
> Paul
>
>
> On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatracker <
> [email-masked]> wrote:
>
>> Reviewer: Kyle Rose
>> Review result: Has Issues
>>
>> I have reviewed this document as part of the security directorate's
>> ongoing
>> effort to review all IETF documents being processed by the IESG.  These
>> comments were written primarily for the benefit of the security area
>> directors.
>>  Document editors and WG chairs should treat these comments just like any
>> other
>> last call comments.
>>
>> This document Has Issues.
>>
>> I don't actually have a lot to say about this document from a security
>> perspective: its purpose is to describe, using YANG, a data model
>> intended as
>> the basis for configuration schemas developed for implementations of the
>> Interface to Network Security Functions (I2NSF) framework. Security
>> considerations for the most part should be addressed in documents
>> describing
>> system architecture or normatively detailing how implementations are to
>> make
>> use of the data model described here. I'm not going to relitigate any such
>> issues here.
>>
>> The main issues I found in this document are ones that I, as someone not
>> terribly familiar with YANG, found troubling from a general engineering
>> perspective. These are best illustrated by example:
>>
>>  * Why are `ipvX-prefix`, `-range`, and (the misleadingly-named)
>> `-address`
>>  defined here? These concepts are generic enough that they should be in
>> modules
>>  of their own to minimize variation among data models and the errors that
>> will
>>  inevitably result from capturing the same concept in slightly different
>> ways
>>  that are not obvious to the user. * Overall, I have to imagine that much
>> of
>>  the `nsfintf` data model is generic enough that it should be captured
>>  externally. For instance, `tcp-flags`, `port-range`, `flow-label`,
>> `dscp`,
>>  etc. are generally useful elements of an abstract transport data model
>> that
>>  they shouldn't be defined here, but rather incorporated from an external
>> data
>>  model that is maintained by those in (for example) the transport area.
>>
>> Am I just commenting on the YANG ecosystem in general? If these are
>> standard
>> practices, then the overall ecosystem has major latent problems. Ideally,
>> a
>> particular YANG module seems like it should describe only those elements
>> defined at a particular layer, in this case rules and actions, and use
>> reference external modules for elements that are defined at lower layers.
>>
>> Also some nits:
>>
>>  * `ipvX-address` describes a subspace of the global IPvX address space,
>> not a
>>  single address. The name is going to cause problems. * The descriptions
>> given
>>  are often (usually?) just restatements of the entity name. Example is
>>  `identity priority-by-order` described as "Identity for priority by
>> order".
>>  The description should provide some value for the user beyond simply
>> restating
>>  the name. * The headings in section 5 should be clearly labeled with the
>> word
>>  "example", such as "Example Security Requirement 1". * IPv6 addresses in
>> text
>>  MUST be represented in lowercase, according to RFC 5952 section 4.3.
>>
>>
>> _______________________________________________
>> I2nsf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 3 Feb 2022 09:28:21 +0900

Hi Kyle,
No problem:-)

I will address your comments to remove the redundancy.

Thanks.

Best Regards,
Paul

2022년 2월 3일 (목) 오전 8:23, Kyle Rose <[email-masked]>님이 작성:

>>>  Document editors and WG chairs should treat these comments just like
>>> any other
>>> last call comments.
>>>
>>>  of their own to minimize variation among data models and the errors
>>> that will
>>>  that are not obvious to the user. * Overall, I have to imagine that
>>> much of
>>>  they shouldn't be defined here, but rather incorporated from an
>>> external data
>>> practices, then the overall ecosystem has major latent problems.
>>> Ideally, a
>>>  the name. * The headings in section 5 should be clearly labeled with
>>> the word
>>>  "example", such as "Example Security Requirement 1". * IPv6 addresses
>>> in text
>> --
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>