Hi Roman, Here is the revision of the I2NSF Capability Data Model Draft: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-21
I attach the revision letter. Thanks for your support. Best Regards, Paul On Tue, Nov 2, 2021 at 6:10 AM Roman Danyliw <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
Revision-Letter-for-draft-ietf-i2nsf-capability-data-model-21-20211113.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
