Dan, I see. Thanks for your kind guide.
Best Regards, Paul 2022년 1월 27일 (목) 오전 12:44, Dan Romascanu <droma...@gmail.com>님이 작성: > 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. > > 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 >>> >> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department Head Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: paulje...@skku.edu, jaehoon.p...@gmail.com Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
