Re: [I2nsf] Review of draft-ietf i2nsf-nsf-facing-17 was Re: Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <[e-mail]> 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" <[e-mail]>
> To: "Kyle Rose" <[e-mail]>; "tom petch" <[e-mail]>
> Cc: "secdir" <[e-mail]>; <[e-mail]>; "JungSoo Park"
> <[e-mail]>; "Last Call" <[e-mail]>; "Yunchul Choi"
> <[e-mail]>; "Patrick Lingga" <[e-mail]>;
> "skku-iotlab-members" <[e-mail]>; "Mr.
> Jaehoon Paul Jeong" <[e-mail]>
> 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
> <[e-mail]>
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/i2nsf
> > >
> >
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>