Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-05

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sun, 9 Aug 2020 20:02:03 +0900

Hi Roman,
Could you check my revision on I2NSF Capability YANG Data Model and let me
know
if there are further comments?

Thanks.

Best Regards,
Paul

On Mon, Jul 13, 2020 at 10:03 PM Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> 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: [email-masked], [email-masked]
> 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 <[email-masked]> 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
>> [email-masked]
>> 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: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 24 Aug 2020 12:08:56 +0000

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 <[email-masked]>
Sent: Monday, July 13, 2020 9:04 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; Susan Hares <[email-masked]>; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
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?

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: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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?

(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?

(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)

(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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 24 Aug 2020 23:48:31 +0900

Hi Roman,
No problem.

I will address your further comments this week.

For draft-dong-i2nsf-asf-config, I prefer option (a), that is, removing the
references to the capabilities from draft-dong-i2nsf-asf-config.

Thanks for your valuable feedback.

Best Regards,
Paul

On Mon, Aug 24, 2020 at 9:08 PM Roman Danyliw <[email-masked]> 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:
>
>
>
> [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
>
>
>
> 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 <[email-masked]>
> *Sent:* Monday, July 13, 2020 9:04 AM
> *To:* Roman Danyliw <[email-masked]>
> *Cc:* [email-masked]; Susan Hares <[email-masked]>; skku-iotlab-members <
> [email-masked]>; Mr. Jaehoon Paul Jeong <
> [email-masked]>
> *Subject:* Re: [I2nsf] AD Review of
> draft-ietf-i2nsf-capability-data-model-05
>
>
>
> Hi Roman,
>
> (1)     IDNits returned the following valid comment about references (many
> of the issue is noted were in the YANG module)
> (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?
>
> 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
> 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
> 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.
> 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.

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 24 Aug 2020 15:05:50 +0000

Hi WG!

Any objections to implementing “option (a)” (details below):
“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 [draft-ietf-i2nsf-capapbility-data-model] document gets published”
Regards,
Roman
From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: Monday, August 24, 2020 10:49 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; Susan Hares <[email-masked]>; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-05

Hi Roman,
No problem.

For draft-dong-i2nsf-asf-config, I prefer option (a), that is, removing the references to the capabilities from draft-dong-i2nsf-asf-config.

Best Regards,
Paul

On Mon, Aug 24, 2020 at 9:08 PM Roman Danyliw <[email-masked]<mailto:[email-masked]>> 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)

[Roman] See Section 7

--[ snip ]--
7.  IANA Considerations

Regards,
Roman

From: Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 13, 2020 9:04 AM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>; skku-iotlab-members <[email-masked]<mailto:[email-masked]>>; Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>
Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-05

Hi Roman,

Best Regards,
Paul

OLD

OLD

NEW

OLD

Regards,
Roman

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 25 Aug 2020 21:17:59 +0900

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

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 25 Aug 2020 15:46:14 +0000

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 <[email-masked]> On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Tuesday, August 25, 2020 8:18 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-05

Hi Roman,

Thanks.

Best Regards,
Paul

[Roman] See Section 7

--[ snip ]--
7.  IANA Considerations

(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?

Regards,
Roman

Hi Roman,

Thanks for your valuable comments and help..

Best Regards,
Paul

(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.

OLD

OLD

(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.

NEW

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 26 Aug 2020 02:07:55 +0900

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 <[email-masked]> 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:
>
>
>
> (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 {
>
>       "RFC 8329 <https://tools.ietf.org/html/rfc8329>: Framework for
> Interface to Network Security
>
>       "RFC 8329 <https://tools.ietf.org/html/rfc8329>: Framework for Interface to Network Security
>
> *From:* I2nsf <[email-masked]> *On Behalf Of * Mr. Jaehoon Paul
> Jeong
> *Sent:* Tuesday, August 25, 2020 8:18 AM
> *Cc:* [email-masked]; skku-iotlab-members <
> [email-masked]>; Susan Hares <[email-masked]>
> (28)       Section 6.1..  In the advanced-nsf-capability section, there
> are multiple normative references to draft-dong-i2nsf-asf-config-01, an
> that they are described in detail in draft-ietf-i2nsf-capability..  For
> draft-ietf-i2nsf-capability-04 to be an unexpected reference..  There is no
> draft-ietf-i2nsf-capability-04 to be an unexpected reference..  There is no
> attacks..

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 25 Aug 2020 17:16:03 +0000

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 <[email-masked]>
Sent: Tuesday, August 25, 2020 1:08 PM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; skku-iotlab-members <[email-masked]>; Susan Hares <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
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:

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

Thanks.

Best Regards,
Paul

On Wed, Aug 26, 2020 at 12:46 AM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul!

OLD:
  identity whitelists {

NEW:

  identity allow-list {

    description

    reference

  }

Regards,
Roman

From: I2nsf <[email-masked]<mailto:[email-masked]>> On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Tuesday, August 25, 2020 8:18 AM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; skku-iotlab-members <[email-masked]<mailto:[email-masked]>>; Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-05

Hi Roman,

Thanks.

Best Regards,
Paul

[Roman] See Section 7

--[ snip ]--
7.  IANA Considerations

Regards,
Roman

Hi Roman,

Best Regards,
Paul

OLD

OLD

NEW

OLD

Regards,
Roman

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 26 Aug 2020 09:10:40 +0900

Roman,
Thanks for your kind help and guidance.

Best Regards,
Paul

On Wed, Aug 26, 2020 at 2:16 AM Roman Danyliw <[email-masked]> wrote:

> *Sent:* Tuesday, August 25, 2020 1:08 PM
> [email-masked]>; Susan Hares <[email-masked]>; Mr.
> Jaehoon Paul Jeong <[email-masked]>
> *From:* I2nsf <[email-masked]> *On Behalf Of *Mr. Jaehoon Paul
> Jeong