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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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]> 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]>
> *Sent:* Monday, July 13, 2020 9:04 AM
> *To:* Roman Danyliw <[e-mail]>
> *Cc:* [e-mail]; Susan Hares <[e-mail]>; skku-iotlab-members <
> [e-mail]>; Mr. Jaehoon Paul Jeong <
> [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], [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]> 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]
> 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], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>