Re: [I2nsf] AD Review of draft-ietf-i2nsf-nsf-facing-interface-dm-10
identified by > either a group id or group name. The group-to-IP address and user-to-group > mappings are assumed to be provided by the unified user management system > via network. > > > > > > ** Section 7. Thanks for adding the language about identity information > per “container user and group”. I recommend some editorial polish. > > > > OLD > >In this YANG data module, note that the identity information of users > >can be exchanged for security policy configuration based on a user's > >information. This implied that to improve the network security there > >is a tradeoff between a user's information privacy and network > >security. For container users-conditions in this YANG data module, > >the identity information of users can be exchanged between Security > >Controller and an NSF for security policy configuration based on > >users' information. Thus, for this exchange of the identity > >information of users, there is a proportional relationship between > >the release level of a user's privacy information and the network > >security strength of an NSF. > > > > NEW > > > > Policy rules identifying specified users and user groups can be specified > with “rule/condition-clause-container/context-condition/users-condition”. > As with other data in this YANG module, this user information is provided > by the Security Controller to the NSFs and is protected via the transport > and access control mechanisms described above. > > > > ** Section 6. Per "For security requirements ... described in Appendix > A", there is no Appendix A in this document. > > > > [Roman] Thanks for the edits. It introduced a reference typo s/ described > in Section Configuration Examples of > [I-D.ietf-i2nsf-capability-data-model]/ described in Appendix A of > [I-D.ietf-i2nsf-capability-data-model]/ > > > > > > ** Idnits returned: > > > > == Unused Reference: 'I-D.ietf-i2nsf-sdn-ipsec-flow-protection' is > defined > > on line 4572, but no explicit reference was found in the text > > > > == Unused Reference: 'RFC8335' is defined on line 4641, but no explicit > > reference was found in the text > > > > > > > > > > *From:* Mr. Jaehoon Paul Jeong > *Sent:* Tuesday, February 2, 2021 11:45 AM > *To:* Roman Danyliw > *Cc:* i2nsf@ietf.org; Dr. Jinyong (Tim) Kim ; > Patrick Lingga ; 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-nsf-facing-interface-dm-10 > > > > Hi Roman, > > Tim, Patrick and I have revised the NSF-Facing Interface YANG Data Model > > according to your comments: > > https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-11 > > > > I attach the revision letter to explain how I have reflected your comments > on the revision. > > > > Thanks for your valuable comments and encouragement. > > > > Best Regards, > > Paul > > > > > > On Sat, Oct 31, 2020 at 11:47 AM Roman Danyliw wrote: > > Hi! > > I performed an AD review on draft-ietf-i2nsf-nsf-facing-interface-dm-10. > Thanks for writing it. > > My feedback is as follows: > > [snip] > > ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] AD Review of draft-ietf-i2nsf-nsf-facing-interface-dm-10
n-ipsec-flow-protection' is defined on line 4572, but no explicit reference was found in the text == Unused Reference: 'RFC8335' is defined on line 4641, but no explicit reference was found in the text From: Mr. Jaehoon Paul Jeong Sent: Tuesday, February 2, 2021 11:45 AM To: Roman Danyliw Cc: i2nsf@ietf.org; Dr. Jinyong (Tim) Kim ; Patrick Lingga ; skku-iotlab-members ; Mr. Jaehoon Paul Jeong Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-nsf-facing-interface-dm-10 Hi Roman, Tim, Patrick and I have revised the NSF-Facing Interface YANG Data Model according to your comments: https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-11 I attach the revision letter to explain how I have reflected your comments on the revision. Thanks for your valuable comments and encouragement. Best Regards, Paul On Sat, Oct 31, 2020 at 11:47 AM Roman Danyliw mailto:r...@cert.org>> wrote: Hi! I performed an AD review on draft-ietf-i2nsf-nsf-facing-interface-dm-10. Thanks for writing it. My feedback is as follows: [snip] ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] AD Review of draft-ietf-i2nsf-nsf-facing-interface-dm-10
Hi Roman, We authors will revise our draft according to your review comments. Thanks. Best Regards, Paul On Sat, Oct 31, 2020 at 11:47 AM Roman Danyliw wrote: > Hi! > > I performed an AD review on draft-ietf-i2nsf-nsf-facing-interface-dm-10. > Thanks for writing it. > > My feedback is as follows: > > ** (This is the most significant issue) This document makes a significant > number of normative references to the capability information model. > However, the WG has decided not to publish this document ( > https://mailarchive.ietf.org/arch/msg/i2nsf/5SXo9QlIvtIEDOjHKA-d2jM1TUc/). > These are many dependencies to resolve. These are an incomplete list I > noted: > > -- Section 1. There are a multiple references to the ECA model from > [I-D.ietf-i2nsf-capability] > > -- Section 4.1. The text is relying on the deprecated > draft-ietf-i2nsf-capability to describe the resolution strategies and > default action. > > -- Section 4.2. This section relies on draft-ietf-i2nsf-capability to > explain the event clause > > -- Section 4.3. The condition clause depends on ietf-i2nsf-capability. > > -- Section 4.4. The action clause depends on ietf-i2nsf-capability. The > definition of an ingress, egress and log action are not explained. > > -- YANG. identity target-device (and all derived from it) relies on > draft-ietf-i2nsf-capability > > -- YANG. identity content-security-controls relies on > draft-ietf-i2nsf-capability. > > -- YANG. identity attack-mitigation-control relies on > draft-ietf-i2nsf-capability. > > -- YANG. identity ingress-, egress- and default-action rely on > draft-ietf-i2nsf-capability. > > ** Section 1. Editorial. s/ NSF-Facing Interface in Interface to Network > Security Functions (I2NSF) [RFC8329]/NSF-Facing Interface in the Interface > to Network Security Functions (I2NSF) architecture [RFC8329]/ > > ** Section 1. Per "Security policy configuration for advanced network > security functions can be defined in future.", what is this referencing? > Only a few sentences into the introduction the scope of the module isn't > clear. What makes it "advanced"? > > ** Section 4. "Advanced network security functions can be defined in > future.", this is the second time in two pages that references are made to > advanced functions. What is that referencing? > > ** Section 4. Editorial. The bulleted list of the YANG module describing > a policy rule and ECA clauses was stated at the end of Section 1 (at the > top of page 3) and repeated almost verbatim again in Section 4 (at the > bottom of page 4). It likely doesn't need to be said twice. > > ** Section 4.1. Editorial. The sentence "This YANG tree diagram shows > the general I2NSF security policy rule for generic network security > functions" is repeated twice. > > ** Section 4.1. Typo. s/resolutation/resolution/ > > ** Section 4.2. These sentences follow each other and are nearly > identical: >This section shows the YANG tree diagram for an event clause for >I2NSF security policy rules. > >This YANG tree diagram shows an event clause of an I2NSF security >policy rule for generic network security functions. > > ** Section 4.3. In Figure three, there is "pkt-sec-ipv4-geoip" and > "pkt-sec-ipv4-sameip" but in the formal definition of the YANG module in > Section 5, there are "pkt-sec-ipv4-geo-ip" and "pkt-sec-ipv4-same-ip" > > ** Section 4.3. Per "A condition clause of context is defined ... and > geography condition", shouldn't that be a "gen-context-condition"? > > ** Section 4.3. > Note that this document deals only with >simple conditions of advanced network security functions. A >condition clause of more advanced network security functions can be >defined as an extension in future. A condition clause can be >extended according to specific vendor condition features > > Previous text notes the possibility for extensions to advanced network > security features. Here we are talking about extensions to the condition > clause. Do we need a bit of text to explain the extensibility approach? > > ** Section 4.5. What makes something an advanced action? Is it the > difference between a per packet vs. per flow decision? Some other kind of > state? > > ** Section 4.5. Per "An I2NSF IPsec specification is used to define a > method required to manage IPsec parameters for creating IPsec Security > Associations (SAs) between two NSFs through either the IKEv2 protocol or > the Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]" > > -- this workflow of NSF-to-NSF communication is no longer docu
[I2nsf] AD Review of draft-ietf-i2nsf-nsf-facing-interface-dm-10
Hi! I performed an AD review on draft-ietf-i2nsf-nsf-facing-interface-dm-10. Thanks for writing it. My feedback is as follows: ** (This is the most significant issue) This document makes a significant number of normative references to the capability information model. However, the WG has decided not to publish this document (https://mailarchive.ietf.org/arch/msg/i2nsf/5SXo9QlIvtIEDOjHKA-d2jM1TUc/). These are many dependencies to resolve. These are an incomplete list I noted: -- Section 1. There are a multiple references to the ECA model from [I-D.ietf-i2nsf-capability] -- Section 4.1. The text is relying on the deprecated draft-ietf-i2nsf-capability to describe the resolution strategies and default action. -- Section 4.2. This section relies on draft-ietf-i2nsf-capability to explain the event clause -- Section 4.3. The condition clause depends on ietf-i2nsf-capability. -- Section 4.4. The action clause depends on ietf-i2nsf-capability. The definition of an ingress, egress and log action are not explained. -- YANG. identity target-device (and all derived from it) relies on draft-ietf-i2nsf-capability -- YANG. identity content-security-controls relies on draft-ietf-i2nsf-capability. -- YANG. identity attack-mitigation-control relies on draft-ietf-i2nsf-capability. -- YANG. identity ingress-, egress- and default-action rely on draft-ietf-i2nsf-capability. ** Section 1. Editorial. s/ NSF-Facing Interface in Interface to Network Security Functions (I2NSF) [RFC8329]/NSF-Facing Interface in the Interface to Network Security Functions (I2NSF) architecture [RFC8329]/ ** Section 1. Per "Security policy configuration for advanced network security functions can be defined in future.", what is this referencing? Only a few sentences into the introduction the scope of the module isn't clear. What makes it "advanced"? ** Section 4. "Advanced network security functions can be defined in future.", this is the second time in two pages that references are made to advanced functions. What is that referencing? ** Section 4. Editorial. The bulleted list of the YANG module describing a policy rule and ECA clauses was stated at the end of Section 1 (at the top of page 3) and repeated almost verbatim again in Section 4 (at the bottom of page 4). It likely doesn't need to be said twice. ** Section 4.1. Editorial. The sentence "This YANG tree diagram shows the general I2NSF security policy rule for generic network security functions" is repeated twice. ** Section 4.1. Typo. s/resolutation/resolution/ ** Section 4.2. These sentences follow each other and are nearly identical: This section shows the YANG tree diagram for an event clause for I2NSF security policy rules. This YANG tree diagram shows an event clause of an I2NSF security policy rule for generic network security functions. ** Section 4.3. In Figure three, there is "pkt-sec-ipv4-geoip" and "pkt-sec-ipv4-sameip" but in the formal definition of the YANG module in Section 5, there are "pkt-sec-ipv4-geo-ip" and "pkt-sec-ipv4-same-ip" ** Section 4.3. Per "A condition clause of context is defined ... and geography condition", shouldn't that be a "gen-context-condition"? ** Section 4.3. Note that this document deals only with simple conditions of advanced network security functions. A condition clause of more advanced network security functions can be defined as an extension in future. A condition clause can be extended according to specific vendor condition features Previous text notes the possibility for extensions to advanced network security features. Here we are talking about extensions to the condition clause. Do we need a bit of text to explain the extensibility approach? ** Section 4.5. What makes something an advanced action? Is it the difference between a per packet vs. per flow decision? Some other kind of state? ** Section 4.5. Per "An I2NSF IPsec specification is used to define a method required to manage IPsec parameters for creating IPsec Security Associations (SAs) between two NSFs through either the IKEv2 protocol or the Security Controller [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]" -- this workflow of NSF-to-NSF communication is no longer documented in ietf-i2nsf-sdn-ipsec-flow-protection (Section 7.1. and 7.2 were removed in -08) after my AD review. Where is the interplay of two NSFs described in the I2NSF architecture? Could that be explained or cited here. -- It seems like the Security Considerations should discuss the channel security this is enabling ** Section 5. (a) The main objective of this data model is to provide both an information model and the corresponding YANG data model of I2NSF NSF- Facing Interface. (b)The semantics of the data model must be aligned with the information model of the N
