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