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 protected]> On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Tuesday, August 25, 2020 8:18 AM
To: Roman Danyliw <[email protected]>
Cc: [email protected]; skku-iotlab-members <[email protected]>;
Mr. Jaehoon Paul Jeong <[email protected]>; Susan Hares <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>>
Sent: Monday, July 13, 2020 9:04 AM
To: Roman Danyliw <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Susan Hares
<[email protected]<mailto:[email protected]>>; skku-iotlab-members
<[email protected]<mailto:[email protected]>>;
Mr. Jaehoon Paul Jeong <[email protected]<mailto:[email protected]>>
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: +82-31-299-4957
Email: [email protected]<mailto:[email protected]>,
[email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>,
[email protected]<mailto:[email protected]>
Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
