Éric Vyncke has entered the following ballot position for draft-ietf-i2nsf-nsf-monitoring-data-model-16: No Objection
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/about/groups/iesg/statements/handling-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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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. Thank you also for addressing my previous DISCUSS points as well as many of my COMMENT points. I sincerely believe that the changes have improved the document. ! Please note that there is a warning about the syntax of the YANG module ! 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>). # Previous DISCUSS (just kept for archiving) ## 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? # COMMENTS ## 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] https://www.ietf.org/mailman/listinfo/i2nsf
