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

[Roman Danyliw <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, August 25, 2020 1:08 PM
To: Roman Danyliw <[e-mail]>
Cc: [e-mail]; skku-iotlab-members <[e-mail]>; Susan Hares <[e-mail]>; Mr. Jaehoon Paul Jeong <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Tuesday, August 25, 2020 8:18 AM
To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; skku-iotlab-members <[e-mail]<mailto:[e-mail]>>; Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 13, 2020 9:04 AM
To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>; skku-iotlab-members <[e-mail]<mailto:[e-mail]>>; Mr. Jaehoon Paul Jeong <[e-mail]<mailto:[e-mail]>>
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: [phone]
Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/i2nsf



--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Computer Science and Engineering
Sungkyunkwan University
Office: [phone]
Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
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: [phone]
Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>