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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 13 Jul 2020 22:03:59 +0900

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
>