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

[tom petch <[e-mail]>]

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
>
> 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
> >
>