Roman, Thanks for your kind help and guidance. Best Regards, Paul
On Wed, Aug 26, 2020 at 2:16 AM Roman Danyliw <r...@cert.org> wrote: > Hi Paul! > > > > Thanks for all of these revisions. I’ve changed the document state to > start IETF LC. > > > > Regards, > > Roman > > > > *From:* Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com> > *Sent:* Tuesday, August 25, 2020 1:08 PM > *To:* Roman Danyliw <r...@cert.org> > *Cc:* i2nsf@ietf.org; skku-iotlab-members < > skku-iotlab-memb...@googlegroups.com>; Susan Hares <sha...@ndzh.com>; Mr. > Jaehoon Paul Jeong <jaehoon.p...@gmail.com> > *Subject:* Re: [I2nsf] AD Review of > draft-ietf-i2nsf-capability-data-model-05 > > > > Roman, > > I have used option (3) by adding rudimentary text for each leaf for > advanced-nsf-capabilities. > > I have also replaced "whitelists" with "allow-list". > > > > Here is the revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-08 > > > > You can see the differences between -07 version and -08 version for those > updates as follows: > > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-i2nsf-capability-data-model-08.txt > > > > > If you have further comments, please let me know. > > > > Thanks. > > > > Best Regards, > > Paul > > > > On Wed, Aug 26, 2020 at 12:46 AM Roman Danyliw <r...@cert.org> wrote: > > Hi Paul! > > > > Thanks for the quick update. This change removed the explicit link to > draft-dong-i2nsf-asf-config. However, now the document has a number of > undocumented elements of the YANG model under advanced-nsf-capability. > Citing RFC8329 is helpful to link them to NSF capabilities, but this > doesn’t explain the differences between these YANG elements. I thinking > there are a couple of options: > > > > (1) remove advanced-nsf-capabilities entirely > > > > (2) leave only a “top-level container” named advanced-nsf-capabilities and > specify this no further. Some text is required to explain that the > advanced-nsf-capabilities is an extension point. > > > > (3) leave the text as is in -07, and add rudimentary text explaining each > of the leaves in advanced-nsf-capabilities as being extension points for > particular advanced capabilities (and explain the differences between them) > > > > As a separate matter and I should have noticed it earlier, I see the use > of the language “whitelist”. In the spirit of reconsidering language that > some consider exclusionary, could you please (i.e., > s/whitelist/allow-list/): > > > > OLD: > > identity whitelists { > > base anti-virus-capability; > > description > > "Identity for advanced NSF Anti-Virus Whitelists capability"; > > reference > > "RFC 8329 <https://tools.ietf.org/html/rfc8329>: Framework for > Interface to Network Security > > Functions - Advanced NSF Anti-Virus Whitelists capability"; > > } > > > > NEW: > > identity allow-list { > > base anti-virus-capability; > > description > > "Identity for advanced NSF Anti-Virus Allow List capability"; > > reference > > "RFC 8329 <https://tools.ietf.org/html/rfc8329>: Framework for > Interface to Network Security > > Functions - Advanced NSF Anti-Virus Allow List capability"; > > } > > > > Regards, > > Roman > > > > *From:* I2nsf <i2nsf-boun...@ietf.org> *On Behalf Of *Mr. Jaehoon Paul > Jeong > *Sent:* Tuesday, August 25, 2020 8:18 AM > *To:* Roman Danyliw <r...@cert.org> > *Cc:* i2nsf@ietf.org; skku-iotlab-members < > skku-iotlab-memb...@googlegroups.com>; Mr. Jaehoon Paul Jeong < > jaehoon.p...@gmail.com>; Susan Hares <sha...@ndzh.com> > *Subject:* Re: [I2nsf] AD Review of > draft-ietf-i2nsf-capability-data-model-05 > > > > Hi Roman, > > I have addressed your two comments in the revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-07 > > > > - Addition of RFC 3688 in Normative References > > - Removal of the references for draft-dong-i2nsf-asf-config from the draft > > > > Please move our draft forward. > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Mon, Aug 24, 2020 at 9:08 PM Roman Danyliw <r...@cert.org> wrote: > > Hi Paul! > > (my apologies. These email got stuck in my outbox and was intended to go > out when I made the state change in the data tracker) > > > > Thanks for the extensive changes you made in -06 and my apologizes in the > delay in responding. All feedback but the following has been addressed: > > > > (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 > > > > [Paul] => There is no reference to RFC3688 (The IETF XML Registry). > Could you doublecheck your comment to let me follow it? > > > > [Roman] See Section 7 > > > > --[ snip ]-- > > 7. IANA Considerations > > > > This document requests IANA to register the following URI in the > > "IETF XML Registry" [RFC3688]: > > … > > --[ snip ]-- > > > > (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? > > > > (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? > > > > [Paul] => This draft will be developed by I2NSF WG later. > > > > I still have the same question. It doesn’t appear to me that the WG is > currently positioned to do anything with draft-dong-i2nsf-asf-config . > Practically, it isn’t even a WG product, but an individual submission that > wasn’t adopted. It was last updated 22 months ago and expired almost 18 > months ago. Correct me where I have it wrong, but this draft provides a > generic model for the capabilities and draft-dong-i2nsf-asf-config appears > to be acting as an extension for more advancing NSF capabilities. I think > we have (at least) two options: > > > > (a) Remove references to the capabilities derived from > draft-dong-i2nsf-asf-config; if there is energy, consider adopting it in > the WG at some point in the future, and it could update this document > (draft-ietf-i2nsf-capability-data-model); in the meantime this document > gets published > > > > (b) Continue advancing this document and stall awaiting a missing > reference (MISREF) in the RFC Editor queue (just like > draft-ietf-i2nsf-applicability) for something to happen to > draft-dong-i2nsf-asf-config > > > > I have a preference for (a) because I don’t see value in blocking the > publication of a named deliverable of the WG for an unadopted (individual), > expired draft; and this approach doesn’t preclude future enhancements (as > proposed by draft-dong-i2nsf-asf-config). What does everyone else think? > > > > Regards, > > Roman > > > > > > > > *From:* Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com> > *Sent:* Monday, July 13, 2020 9:04 AM > *To:* Roman Danyliw <r...@cert.org> > *Cc:* i2nsf@ietf.org; Susan Hares <sha...@ndzh.com>; skku-iotlab-members < > skku-iotlab-memb...@googlegroups.com>; Mr. Jaehoon Paul Jeong < > jaehoon.p...@gmail.com> > *Subject:* Re: [I2nsf] AD Review of > draft-ietf-i2nsf-capability-data-model-05 > > > > Hi Roman, > > I (as an editor) have revised the I2NSF Capability Data Model Draft and > posted it into the IETF repository: > > https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-06 > > > > Here is the revision letter to explain how to address your comments. > > If you are satisfied with this revision, could you move this draft to the > IESG evaluation? > > > > Thanks for your valuable comments and help.. > > > > Best Regards, > > Paul > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Computer Science and Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.p...@gmail.com, paulje...@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > > > > On Wed, May 13, 2020 at 7:11 AM Roman Danyliw <r...@cert.org> wrote: > > 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 > > > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Computer Science and Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.p...@gmail.com, paulje...@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Computer Science and Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.p...@gmail.com, paulje...@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.p...@gmail.com, paulje...@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf