Ballot for draft-ietf-i2nsf-capability-data-model
Discuss
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Thank you for the work put into this document. While I do appreciate that a data model (this document) is derived from an information model, I am concerned that the information model is an expired draft whereas I would expect the information model being published first. Else, what is the use of the information model ? What was the WG reasoning behind 'putting the cart before the horses' ? My concern is that by publishing the YANG model, there is nearly no way to change the information model anymore. Please find below a couple of non-blocking COMMENT points but also a couple of blocking DISCUSS points around IPv6. They should be easy to resolve. I would hate to have NSF having basic IPv6 capabilities that cannot be configured by using the YANG model of this document. I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 4.1 -- It is quite common to apply conditions based on the whole IPv6 extension header chain (i.e., presence of destination option header or wrong order of the extension headers). Why is there no such capabilities in this YANG module ? The only one is 'identity ipv6-next-header' that applies only to the first extension header. What is the difference between 'identity ipv6-protocol' and 'identity ipv6-next-header' ? There is no 'protocol' field in the IPv6 header. While fragmented IPv4 packets are part of the conditions ('identity ipv4-fragment-flags'), there is no equivalent in IPv6.
-- Section 4.1 -- May be am I misreading the YANG tree, but, I see no 'sctp-capability' in the set of 'condition-capabilities' (even is SCTP is not heavily used). Is there a real reason to have two related containers ? generic-nsf-capabilities and advanced-nsf-capabilities. Why not a single one ? Unsure what is meant by 'range' in 'identity range-ipv*-address'. Usually, addresses are filtered/matched by using a prefix length and not a range (that is difficult to implement in hardware). Is there a reason why ICMP(v6) codes are not part of the conditions ?
Thanks for addressing my various comments. Clearing my discuss. One nit: identity ipv6-geo-ip { base ipv6-capability; description "Identity for IPv4 geography condition capability"; That should probably be "Identity for IPv6 geography..."
I support Eric's DISCUSS position about the information model vs. data model publications. The smashed-together list of references at the top of Section 5 could use some formatting. I tripped over several of the editorial points Barry found. Here's one more. In Section 3: o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). Block malicious users "for" IPv6 traffic? I don't understand. Perhaps "block IPv6 traffic from malicious users"?
There are many elements of the YANG module whose semantics seem underspecified to me. I noted quite a few in the COMMENT section, and I hope that those aspects of my comments are clear (as it would be substantial effort to partition the comments and move the questions of unclear semantics into the discuss section), but I am happy to assist in the classification if needed. I think that the data nodes of this module as written are probably not reflecting the intent -- it seems that the only elements of the 'nsf' list are the string nsf-name; there is no "uses nsf-capabilities" stanza to bring in the grouping that contains all the interesting parts. Specifically, I do not see how the tree diagram reflects the current module. I'm surprised to not see any discussion of privacy considerations -- some of the features that we define capability indicators for are highly sensitive and/or privileged operations (e.g., listening to VoIP/VoLTE audio to identify individuals, web filtering) that inherently require access to individuals' private data. Not only should we note that private information is made accessible in this manner, but we should also reiterate that the nodes/entities given access to this data need to be tightly secured and monitored, to prevent leakage or other unauthorized disclosure of private data. I also think we need to mention that authentication and proper authorization will be needed to register as an NSF providing these capabilities. The examples do not seem to conform to the current module structure (e.g., exact-fourth-layer-port-num and range-fourth-layer-port-num). I worry a little bit that even the structure of the tree risks "imposing functional requirements or constraints" upon NSF developers (in the words of the framework). How would, for example, SCTP capabilities be indicated, let alone QUIC? (With an augmentation, clearly, but is that undue burden?) While the classification into ingress/egress/log is natural, it also may be found limiting; consider, for example, a setup involving port mirroring -- is that an ingress action or egress? If traffic is dropped as part of a different ingress filtering capability, does it still get sent to the port mirror?
I support Benjamin's discuss on the lack of semantics. It is impossible to review the transport related parameters for correctness as they lack the semantics to understand if they do map to protocol values. This discuss is more a place holder to be aware that this document needs to re-reviewed after having addressed by transport people.
The datatracker should indicate that this draft replaces draft-hares-i2nsf-capability-data-model. I support the DISCUSS positions from Erik and Ben.
While most of these comments are editorial, some of them are dealing with text that's difficult to understand because of the editorial issues. Please consider these: — Section 1 — As the industry becomes more sophisticated and network devices (e.g., Internet of Things, Self-driving vehicles, and smartphone using Voice over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a lot of problems described in [RFC8192]. This sentence seems a bit fractured. What about network devices? It looks like there’s something missing after the parenthetical. Please re-work this sentence. — Section 3 — This section provides as overview of how the YANG data model can be Typo: “provides an overview”. The configuration of advanced security functions over the NSF-Facing Interface is used to configure the security policy rules of advanced network security functions (e.g., anti-virus and Distributed-Denial- of-Service (DDoS) attack mitigator), respectively, according to the capabilities of NSFs registered with the I2NSF Framework. I don’t see what “respectively” refers to, as the sentence only talks about configuring one thing (“the security policy rules of advanced network security functions”). Also, it seems odd to say “the configuration of … is used to configure …”. Probably should fix that. o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). Please consider not making the network administrator male (“he”). o When the Network Operator Management System receives the security policy rule, it automatically sends that security policy rules to appropriate NSFs Change “rules” to singular “rule” to match the first half of the sentence. — Section 7 — You twice say “transport secure transport”, which should just be “secure transport”. o ietf-i2nsf-capability: An attacker could alter the security capabilities associated with an NSF whereby disabling or enabling the evasion of security mitigations. I don’t think “whereby” is the right word here, but I can’t figure out what you’re trying to say well enough to suggest what the right word is. Maybe just “by”? And I don’t know what it means to “disable the evasion of” something. So this sentence needs some work, please. These are the subtrees and data nodes and their sensitivity/vulnerability: Something’s missing here. Maybe just “is”? Maybe something else?