Hi Roman, I have moved RFC 8329 from Informative References to Normative References for the five I2NSF YANG Data Model Drafts:
- I2NSF Capability YANG Data Model Draft https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-23 - I2NSF NSF-Facing Interface YANG Data Model Draft https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-19 - I2NSF Monitoring Interface YANG Data Model Draft https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-14 - I2NSF Consumer-Facing Interface YANG Data Model Draft https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-16 - I2NSF Registration Interface YANG Data Model Draft https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-14 Also, I have moved other RFCs and I-Ds, which are core references, from Informative References to Normative References. In addition, I have moved other RFCs and I-Ds, which are relatively less important references, from Normative References to Informative References. Thanks. Best Regards, Paul On Thu, Jan 27, 2022 at 7:33 AM Roman Danyliw <r...@cert.org> wrote: > Hi! > > > > *From:* Dan Romascanu <droma...@gmail.com> > *Sent:* Wednesday, January 26, 2022 10:44 AM > *To:* Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com> > *Cc:* General Area Review Team <gen-art@ietf.org>; i2...@ietf.org; Last > Call <last-c...@ietf.org>; > draft-ietf-i2nsf-nsf-facing-interface-dm....@ietf.org > *Subject:* Re: [I2nsf] Genart last call review of > draft-ietf-i2nsf-nsf-facing-interface-dm-17 > > > > Hi Paul, > > > > Thank you for your answer and for addressing my comments. I am fine with > all your proposed changes, with one observation. > > > > > => [PAUL] RFC 8329 (Framework for Interface to Network Security > Function) is an > > Informational RFC. If RFC 8329 is moved to Normative Reference, the > ID-NITS tool > (https://www6.ietf.org/tools/idnits) returns an error as follows: > “** Downref: Normative reference to an Informational RFC: RFC 8329” > Thus, we put RFC 8329 as an Informative Reference. > > > > I am aware that placing RFC 8329 as Normative creates a downref. This is > admitted provided that the issue is justified and registered as such ar LC > time. This is a non-blocking comment, anyway, so I will let you and the WG > decide. > > > > [Roman] I believe that all reference to RFC8329 in the Section 4 (the YANG > module) also include a reference to draft-ietf-i2nsf-capability-data-model > which is a normative reference. RFC8329 has additional background on > understanding these particular fields in a larger architectural sense. > > > > Regards, > > Roman > > > > Regards, > > > > Dan > > > > > > On Wed, Jan 26, 2022 at 3:23 PM Mr. Jaehoon Paul Jeong < > jaehoon.p...@gmail.com> wrote: > > Hi Dan, > > Here is the revised draft of NSF-Facing Interface according to your > comments: > > > https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-18 > > > > Patrick and I have worked on the revision. > > > > I attach the revision letter to explain our revision for your comments. > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Tue, Jan 25, 2022 at 7:26 PM Dan Romascanu via Datatracker < > nore...@ietf.org> 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 > i2...@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
