Hi! Thanks for all of the work on draft versions -17 to -20. To make thing easier to track, I'm starting a new thread on the -20 version of the document to comment on my AD review of -16 (https://mailarchive.ietf.org/arch/msg/i2nsf/BJ4GUttBVZRvHGm3m2_bEycNQWI/) and the changes made to address the IESG review in September 2020 (https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ballot/). Unless otherwise mentioned below, please consider any feedback as resolved:
** Section 1. We've polished this sentence a bit. Recommend: OLD Note that this YANG data model constructs the structure of the NSF Monitoring Interface YANG data model [I-D.ietf-i2nsf-nsf-monitoring-data-model] and the NSF-Facing Interface YANG Data Model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. NEW Note that this YANG data model forms the basis of the NSF Monitoring Interface YANG data model [I-D.ietf-i2nsf-nsf-monitoring-data-model] and the NSF-Facing Interface YANG Data Model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. ** Section 8. This YANG module specifies the capabilities for NSFs. Some of the capabilities in this document MAY require highly sensitive private data to operate properly. The usage of such capability MUST be reported to the users and permitted before using the private information related to the capability. Using any of the capabilities that require private data MUST preserve the privacy by preventing any leakage or unauthorized disclosure of the private data. I appreciate the inclusion of this new section in response to the original IESG telechat (per Ben Kaduk's discuss position). The current text is right in spirit, but I see the use of all of this normative language as risky. It will likely invite the need for further clarifying text which will be difficult (and unnecessary) to produce. Consider the following alternative to the above. NEW This YANG module specifies the capabilities of NSFs. These capabilities are consistent with the diverse set of network security function in common use in enterprise security operations. The configuration of the capabilities may entail privacy sensitive information as explicitly outlines in Section 9. The NSFs implementing these capabilities may inspect, alter or drop user traffic; and be capable of attributing user traffic to individual users. Due to the sensitivity of these capabilities, notice must be provided to and consent must be received from the users of the network. Additionally, the collected data and associated infrastructure must be secured to prevent the leakage or unauthorized disclosure of this private data. ** References -- RFC8805 should be a normative reference -- idnits says: Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- (needs to be done before the IESG review) Can the shepherd write-up please be updated to reflect that there is a downref with RFC8805 Regards, Roman _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
