Re: [I2nsf] [Last-Call] Genart last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-17

Hi Tom,
As you may know, I as the editor of those I-Ds need to address the comments
from
the IETF community for preparing for the IESG review.

If you have specific comments on I2NSF YANG Data Model Drafts
to improve them, please let me know.

Thanks.

Best Regards,
Paul

On Wed, Jan 26, 2022 at 10:10 PM tom petch <daedulus@btconnect.com> wrote:

> Picking on this e-mail as it is the most recent of those relating to
> nsf-facing -17 and not because this has anything to do with Genart
>
> -17 has introduced a number of errors as a result of changes (which is
> why I was unenthusiastic about the comments made on -16).
>
> It will take me quite a while to go through all the i2nsf I-D in detail
> (again) but meanwhile, the sort of thing that leaps out at me ..
>
> A number of references have been added to this YANG module - these now
> need adding to the I-D References; I see ten at first glance.
>
> The added action 'reject' needs adding to the YANG description in
> several places.
>
> The terminology is drifting out of line with RFC8329 - I do not know if
> this is just something to live with or whether these I-D should contain
> notes along the lines of 'Where RFC8329 says xxxx, we now say AVFRT
> ...'.  And the right answer may depend on whether or not this RFC is
> made Normative.
>
>
> And the TLP in the YANG module is out of date
>
> Tom Petch
>
> On 25/01/2022 10:26, Dan Romascanu via Datatracker wrote:
> > Reviewer: Dan Romascanu
> > Review result: Ready with Issues
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-i2nsf-nsf-facing-interface-dm-17
> > Reviewer: Dan Romascanu
> > Review Date: 2022-01-25
> > IETF LC End Date: 2021-11-23
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > This document defines a YANG data model for configuring security policy
> rules
> > on Network Security Functions (NSF) in the Interface to the Network
> Security
> > Functions (I2NSF) framework. It's a solid, well-written and complete
> document.
> > It needs to be read in the context and together with several other
> documents
> > belonging to the I2NSF deliveries. The document is Ready from the
> perspective
> > of Gen-ART with a couple of minor non-blocking issues and a few editorial
> > problems that could be easily clarified and fixed if needed.
> >
> > Major issues:
> >
> > Minor issues:
> >
> > 1. How can RFC 8329 be only an Informative Reference. The Introduction
> dully
> > states that the YANG module is based upon the framework / architecture
> defined
> > in RFC 8329, and Section 4 uses RFC 8329 in several reference clauses.
> >
> > 2. Section 4.
> >
> >>          leaf frequency {
> >                 type enumeration
> >
> > Is this enumeration sufficient (once, daily, weekly, monthly, yearly)?
> Are not
> > more cases  needed?  more flexibility?
> >
> > Nits/editorial comments:
> >
> > 1. Section 3.3:
> >
> >>   A condition clause of generic network security functions is defined
> as IPv4
> > condition, IPv6 condition, TCP condition, UDP condition, SCTP condition,
> DCCP
> > condition, and ICMP (ICMPv4 and ICMPv6) condition.
> >
> > Should not be rather 'or' instead of 'and'?
> >
> > 2. Section 4:
> >
> > description of identity acces-violation
> >
> >>        "Identity for access-violation. Access-violation system
> >            event is an event when a user tries to access (read, write,
> >            create, or delete) any information or execute commands above
> >            their privilege."
> >
> > 'above their privilege' is vague - probably meaning not-conformant with
> the
> > access profile
> >
> > 3. Section 4
> >
> > identity memory-alarm
> >
> > description
> >           "Identity for memory alarm. Memory is the hardware to store
> >            information temporarily or for a short period, i.e., Random
> >            Access Memory (RAM). A memory-alarm is emitted when the RAM
> >            usage exceeds the threshold.";
> >
> > memory-alarm is emitted when the memory usage is exceeding the threshold
> - RAM
> > example does not really help, the alarm applies to all types of memory
> >
> > 4. Section 4
> >
> >      identity ot {
> >         base device-type;
> >         description
> >           "Identity for Operational Technology devices";
> >       }
> >
> >       identity vehicle {
> >         base device-type;
> >         description
> >           "Identity for vehicle that connects to and shares
> >            data through the Internet";
> >       }
> >
> > reference clauses would help - what is an OT and a 'vehicle' (in this
> context)?
> >
> > 5. Section 4
> >
> >>      identity forwarding {
> >         base egress-action;
> >         description
> >           "Identity for forwarding. This action forwards the packet to
> >            another node in the network.";
> >       }
> >
> > 'This action forwards ... ' sounds odd. The action consists of
> forwarding, but
> > does not perform it. I suggest re-wording. There are a few more such
> instances
> > of 'This action [does] ...
> >
> >
> >
>
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>