Paul Thank you for addressing my DISCUSS points, I have now changed my ballot position into NO OBJECTION.
Thanks for the hard work by the authors Regards -éric From: iesg <[email protected]> on behalf of "Mr. Jaehoon Paul Jeong" <[email protected]> Date: Thursday, 24 March 2022 at 14:24 To: Eric Vyncke <[email protected]>, Benjamin Kaduk <[email protected]> Cc: "[email protected]" <[email protected]>, The IESG <[email protected]>, "[email protected]" <[email protected]>, Patrick Lingga <[email protected]>, Donald Eastlake <[email protected]>, Paul Wouters <[email protected]>, skku-iotlab-members <[email protected]>, "Mr. Jaehoon Paul Jeong" <[email protected]> Subject: Re: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i2nsf-nsf-monitoring-data-model-14: (with DISCUSS and COMMENT) Hi Éric and Benjamin, Here is the revised draft of I2NSF Monitoring Interface YANG Data Model including the addressing of your comments: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-16 If you are fine with this revision, please clear your DISCUSS on the status of the IESG evaluation. Thanks. Best Regards, Paul On Wed, Feb 16, 2022 at 1:35 AM Mr. Jaehoon Paul Jeong <[email protected]<mailto:[email protected]>> wrote: Hi Éric, Here is the revised draft reflecting your comments: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-15 I attach the revision letter to explain how the revision is done by Patrick and me for your comments. [Review by Éric Vyncke and Response by Authors] starts from page 1 in the revision letter. Thanks for your valuable comments and help. Best Regards, Paul On Wed, Feb 9, 2022 at 7:57 PM Éric Vyncke via Datatracker <[email protected]<mailto:[email protected]>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-i2nsf-nsf-monitoring-data-model-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. I really like the approach of binding an information model to a data model even if the information model looks more like a data dictionary. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Please also check the Internet directorate review by Donald Eastlake (thank you BTW) at: https://datatracker.ietf.org/doc/review-ietf-i2nsf-nsf-monitoring-data-model-14-intdir-telechat-eastlake-2022-02-07/ NB: as you may notice, I have not followed Donald's recommendation to raise a DISCUSS on one point, but Donald and I will appreciate an answer of the authors. Special thanks to Linda Dunbar for the shepherd's write-up (even if dated one year ago) including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: While I trust the OPS AD for a final say, I am really surprised that the data model does not re-use existing YANG modules (e.g., RFC 8632 and <https://yangcatalog.org/yang-search/yang_tree/ietf-alarms@2019-09-11>). ## Section 6.2.4 About exporting the "traffic flows", a justification of not using IPFIX is required IMHO. Also missing the MAC address field as not all flows are IPv4 or IPv6 (LLDP, IS-IS, ARP, ...). ## Section 6.3.2 Why is the geo-location not implied by the IP address ? Or rather, how can it be derived if not based on the IP address ? Hence, why duplicating the information which is always bad for data consistency? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Abstract Unsure what a "YANG data diagram" is... Is it a well-known wording for YANG experts or is it "YANG tree diagram"? ## Section 4.1 Suggestion to use "I2NSF gauge" rather than "I2NSF counter" to represent processor temperature. ## Section 6.2.1 The use of "port" is unqualified and therefore ambiguous: is it a layer-4 port ? or an interface port ? Even if the reader may guess the former, let's remove the ambiguity. ## Section 6.2.3 Is there a definition of "sessions" ? I.e., is it a data plane TCP/UDP "connection" or a configuration plane connection ? ## Section 6.2.4 Here also, a qualification of the "port" is welcome. On which interval are the rates computed ? Since the beginning of the flow ? Last minute ? or ? s/arrival-speed/arrival-throughput/ ? Note: the above comments are also applicable in other places in the document. ## Section 6.3.1 Even if most (if not all) DoS are actually DDOS, would a section title of "DoS" be more generic ? ## Section 6.3.2 Should this section be renamed in "malware" ? As the 'virus' event can also be detected locally, is the IP flow information required or even available? Or are NSF never implemented on host for local host security ? What is the "host" here ? In which case is the "host" neither the source nor the destination IP ? Is there a reason why the geo-location is not included in other events ? (see also my DISCUSS point above as geo-location is probably derived from the IP addresses). ## Section 6.4.2 Does the "traffic" include only the data plane or also control/management plane ? Does it count the layer-2 framing ? s/disk-left/disk-space-left/ ? ## Section 6.5.1 Some explanations linking "deep packet inspection" to apparently local user actions will be welcome. For most readers, DPI is for transit traffic not for local actions. ## Section 6.6.1 Are the "drops" caused by policy ? or by hardware/resource error ? As mentioned above, the "peak" and "average" should be qualified by the measurement period. ## Section 8 s/identity ssl-flood/identity tls-flood/ Is there a reason to have a limited set of application protocol ? I.e., why including FTP and not NTP ? Or why defining any at all .. (except perhaps HTTP/HTTPS). For many operators, having separate counters for IPv4/IPv6/non-IP will be useful. # NITS ## Section 1 s/denial of service attacks (DoS)/denial of service (DoS) attacks/ ? ## Section 6.2.3 s/The number of session table exceeded the threshold/The number of sessions exceeded the table threshold/ ? ## Section 8 For "log-action", there is a mix of "action is block" and "action is discarded" (i.e., different tenses). _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
