Hi! I conducted an AD review of draft-ietf-i2nsf-capability-data-model-05. Thanks for the work in getting this document written. My most significant items are around aligning of the text in Section 4 with RFC8329 and the dependency on draft-dong-i2nsf-asf-config-01. My detailed feedback is below.
(1) IDNits returned the following valid comment about references (many of the issue is noted were in the YANG module) == Missing Reference: 'RFC3688' is mentioned on line 1764, but not defined (2) Section 1. Typo. s/[draft-ietf-i2nsf-capability]../ [draft-ietf-i2nsf-capability]./ (3) Section 3. Is there a reason to rely on two expired drafts for terminology -- [draft-ietf-i2nsf-terminology] and [draft-ietf-supa-generic-policy-info-model]? In particular, couldn't RFC3444 provide the needed definitions of data and information models? (4) Section 4. I would have expected somewhere in this overview section an explicit enumeration of which I2NSF interfaces use this YANG module. (5) Section 4. Per "Figure 1 shows the capabilities of NSFs in I2NSF Framework." -- Thanks for reusing the diagram from RFC8329 and annotating it with more detail. It helps connect the documents -- It wasn't clear to me where the "capabilities" are on the diagram -- Is all of the detail under the NSFs (i.e., E, C and A) needed in the diagram? Text doesn't explain it or reference it. If kept, it should be explained and E, C and A should be defined (i.e., saying these correspond to Event, Condition and Action) (6) Global. Editorial. Is there a reason to abbreviate "Mgmt" in "Developer's Mgmt System in the text? Recommend s/Developer's Mgmt System/Developer's Management System/g (7) Section 4. Per "To register NSFs in this way, the Developer's Mgmt System utilizes this standardized capabilities YANG data model through its registration interface.", this confused me a bit. Doesn't the Developer Management System use the model described in draft-ietf-i2nsf-registration-interface-dm for registration? (8) Section 4. Editorial. Per "... those security devices can be easily managed, ...", I might have used "more easily managed". (9) Section 4. Per "The use cases are described below.", where are those use cases described? Is this text a reference to the "Configuration Examples" in Appendix A? (10) Section 4. Per "Note that the NSF-Facing Interface ... and the NSF Monitoring Interface is used to ...", does this text need additional precision based on the definitions in RFC8329. Per RFC8329, the "NSF-Facing Interfaces" consists of the "NSF Operational and Administrative Interface" and a "Monitoring Interface". If draft-dong-i2nsf-asf-config is on the "Monitoring Interface", on which "sub-interface" of the "NSF-Facing Interface" does draft-ietf-i2nsf-nsf-facing-interface-dm belong? (11) Figure 1. Editorial Nit. Is there are reason that the Registration interface has a bidirectional arrow between the network operator management system and the developer management system, but the there is no directionality on the consumer or NSF facing interface? (12) Section 4. The bulleted list under Figure 1 is helpful in describing Figure 1. However, I'd recommend explicitly saying this is an example. Explain the use case up front and then narrate the flow clearly delineating what is in and out of scope of I2NSF. IMO, the text describes a number of internal processing functions which are in scope for standardization - please let me know if I'm reading it wrong. (13) Section 4. Per "If network manager wants to block malicious users with IPv6, the network manager sends the security policy rules to block the users to the Network Operator Mgmt System using I2NSF user ....", can you please clarify "malicious users with IPv6"; is the intent that the network manager is concerned about malicious IPv6 traffic? (14) Section 4. Bullet 1 under Figure 1. Per "a web browser or a software", what's the difference between a browser and software? (15) Section 4. Editorial. Per the second bullet under Figure 1, "If NSFs encounter the malicious packets, it is a tremendous burden for the network manager to apply the rule to block the malicious packets to NSFs one-by-one. This problem can be resolved by managing the capabilities of NSFs.", delete this text. It is a duplicate of what was stated in the first bullet. (16) Section 4. Per the paragraph, "If NSFs encounter the suspicious IPv4 packets, they can ask the Network Operator Mgmt System for information about the suspicious IPv4 packets in order to alter specific rules and/or configurations. When the Network ...", how much of that signaling is in scope for I2NSF? (17) Section 4. Typo. s/suspiciou/suspicious/ (18) Section 5.1. Editorial. s/The model includes NSF capabilities/The model describes NSF capabilities/ (19) Section 5.1. Editorial. "specify" is used twice in the sentence. OLD Time capabilities are used to specify the capabilities to specify when to execute the I2NSF policy rule. NEW Time capabilities are used to specify the capabilities which describe when to execute the I2NSF policy rule. (20) Section 5.1. Editorial. This sentence didn't parse for me. The second contains duplicate text. OLD Event capabilities are used to specify capabilities how to trigger the evaluation of the condition clause of the I2NSF Policy Rule. The defined event capabilities are defined as system event and system alarm. NEW Event capabilities are used to specify the capabilities that describe the event that would trigger the evaluation of the condition clause of the I2NSF Policy Rule. The defined event capabilities are system event and system alarm. (21) Section 5.1. A number of capabilities note that they can be extended which is a helpful feature. For example, "The condition capability can be extended according to specific vendor condition features." However, where is the guidance on doing that? Likewise, it might not be necessary to repeat this statement five times if the extension mechanism is the same. (22) Section 5.1. A number of the described capability types state that they are described in detail in draft-ietf-i2nsf-capability. For example, "The condition capability is described in detail in [draft-ietf-i2nsf-capability]." I had difficulty locating which specific section to review. Also, for the default action capabilities, no described of "pass, drop .. mirror" was found in draft-ietf-i2nsf-capability. Please provide a specific section number for the event, condition, action, resolution strategy and default action in draft-ietf-i2nsf-capability. (23) Section 5.1. Editorial. These sentences didn't parse for me. OLD Action capabilities are used to specify capabilities of how to control and monitor aspects of flow-based NSFs when the event and condition clauses are satisfied. NEW Action capabilities are used to specify the capabilities that describe the control and monitoring aspects of flow-based NSFs when the event and condition clauses are satisfied. OLD Resolution strategy capabilities are used to specify capabilities of how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF. NEW Resolution strategy capabilities are used to specify the capabilities that describe conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF. OLD Default action capabilities are used to specify capabilities of how to execute I2NSF policy rules when no rule matches a packet. NEW Default action capabilities are used to specify the capabilities that describe how to execute I2NSF policy rules when no rule matches a packet. (24) Section 6.1. Update the copyright date and revision date to be in 2020. (25) Section 6.1. Given that draft-ietf-i2nf-monitoring-data-model is referenced in the YANG model for event and system alarm, please make it a normative reference. (26) Section 6.1. identity ingress/egress-action-capability. I found draft-ietf-i2nsf-capability-04 to be an unexpected reference. There is no mention of ingress or egress in that document. (27) Section 6.1. identity pass, drop, reject, alert, mirror. I found draft-ietf-i2nsf-capability-04 to be an unexpected reference. There is no mention of pass, drop, reject, alert or mirror in that document. (28) Section 6.1. In the advanced-nsf-capability section, there are multiple normative references to draft-dong-i2nsf-asf-config-01, an expired, individual draft. Additionally, Section 4 notes how it supports the advanced capabilities. This draft is a substantial portion of the YANG module added in -03. What's the plan on resolving this dependency? (29) Section 6.1. Typo. s/Funtion/Function/ (30) Section 6.1. The list of references in generic-nsf-capabilities don't line up with those in the child leaflist(s). For example, RFC 792 is mentioned in the top level reference list but not in any of the child leaflist (specifically not in leaf-list icmp-capability) (31) Section 6.1. Typo. s/smae/same/ (32) Section 8. A few clarifying updates to the template: OLD These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. ietf-i2nsf-capability: The attacker may provide incorrect information of the security capability of any target NSF by illegally modifying this. NEW These data nodes may be considered sensitive or vulnerable in some network environments. Write operations to these data nodes could have a negative effect on network and security operations. ietf-i2nsf-capability: An attacker could alter the security capabilities associated with an NSF whereby disabling or enabling the evasion of security mitigations. OLD ietf-i2nsf-capability: The attacker may gather the security capability information of any target NSF and misuse the information for subsequent attacks. NEW ietf-i2nsf-capability: An attacker could gather the security capability information of any NSF and use this information to evade detection or filtering. Regards, Roman _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
