Hi Tom, Here is the revised draft addressing your comments: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-21
I attach the revision letter to explain how Patrick and I have addressed your comments. Thanks. Best Regards, Paul On Thu, Feb 3, 2022 at 9:54 PM tom petch <[email protected]> wrote: > With an IESG telechat scheduled for 17th February, I believe that -17 > goes in the wrong direction, with its expanded descriptions, with its > import of packet filters and its addition of application-protocol > identity. > > The I-D has been reviewed many times without comment on the descriptions > so when one reviewer does comment I see that as more a comment on the > reviewer than on the I-D:-) Here it is problematic because the same > YANG definitions appear in other I-D without the expanded descriptions > so there is a mismatch within the set of I-D. And as an AD said > recently, you should reference and not replicate technical matter (which > as ever highlights the lack of a common document for all the things that > are common although I do not advocate tackling that at this stage of the > cycle; perhaps a reissue of the framework document, RFC8329, or an > update of the terminology one) so if expanded descriptions are needed > they should be in one place. The expanded descriptions will need some > editing of the English (perhaps a lot, IMHO) but since I do not think > that they should exist I will not comment further on that. > > Packet filters (RFC8519) were referenced in the framework document and > if they were in this I-D from the start then I might have been ok with > that but I see such a big change so late in the day as the wrong thing > to do especially as I do not see packet filters as the right approach. > They are clumsy. Many YANG modules want to specify a range or a single > value, of IP address and such like and many if not most achieve that > with 'min' and 'max' with 'min = max' for the single value (some use the > absence of max to denote this but for me that is fail danger). With > that approach the model has two leaves > min > max > With the packet filter approach you have e.g. > grouping port-range-or-operator { > choice port-range-or-operator { > case range { > leaf lower-port { > leaf upper-port { > case operator { > <eq neq gte lte> > leaf operator { > leaf port { > which I find overly complex and so prone to misunderstanding and error. > > 'application-protocol' has made an appearance in -17 and I do not know > where that came from. I can see the need for applications in > 'consumer-facing' but it seemed of little relevance in 'nsf-facing' with > its emphasis on ethernet and such like so the difference between the I-D > seemed logical to me. And in incorporating the YANG identity, with > references, you have, as ever, failed to add the references to the I-D > References introducing another ten errors. > > I note the shortening of the names which can be a good idea if it were > done consistently across the I-D and it were done at an earlier stage. > (I note that the examples would appear to be in line with this; on an > earlier occasion they were not). In places though it may have gone too > far; sometimes there are too many fields with an identifier of 'name' > IMHO and a prefix thereto would be helpful. And as ever this introduces > inconsistencies across the set of I-D which should be found and fixed, > not an exercise I am likely to undertake any time soon. And as and when > the terminology diverges from RFC8329 then I think some comment thereon > is called for. > > I realise that multiple versions of nsf-facing have appeared since -17 > but I planned my work to be complete in time for the IETF telechat and > never imagined that there would be such extensive changes so late in the > day I have yet to look at them. I may, I may not. > > Tom Petch > > > ----- Original Message ----- > From: "Mr. Jaehoon Paul Jeong" <[email protected]> > To: "Kyle Rose" <[email protected]>; "tom petch" <[email protected]> > Cc: "secdir" <[email protected]>; <[email protected]>; "JungSoo Park" > <[email protected]>; "Last Call" <[email protected]>; "Yunchul Choi" > <[email protected]>; "Patrick Lingga" <[email protected]>; > "skku-iotlab-members" <[email protected]>; "Mr. > Jaehoon Paul Jeong" <[email protected]> > Sent: Saturday, January 22, 2022 1:57 PM > Subject: Re: [I2nsf] Secdir last call review of > draft-ietf-i2nsf-nsf-facing-interface-dm-16 > > > > 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-interf > ace-dm-17 > <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 protected]> > > 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 protected] > > > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
Revision-Letter-for-I2NSF-NSF-Facing-Interface-Data-Model-21-2022-02-11.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
