Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
I have two points below: 1) The first one should be easy to address: "Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the Stream Control Transmission Protocol (SCTP) will need to be evaluated for applicability. " This sentence is not correct; MPTP and SCTP do not provide any redundancy mechanisms; they simply just provide a reliable transport as TCP does. Therefore I would just remove this sentence here. Further, on this paragraph, it is not clear to me why you say that reliable transport is needed. Especially for some monitoring purposes, unreliable transport might be acceptable as well. Or do you think that all communication for security systems have always to be reliable? I don't think this document discusses things in detail enough to make such an assessment. 2) This second is a very high level concern and I'm not sure if balloting discuss on this is the right thing to do but I definitely would like to get some feedback from the group to better understand this document before publication: This document seem not very security specific to me. To say this in a somehow sloppy way: I have the feeling that if you would just remove the word "security" everywhere in the text, it would still be the same document. I checked the charter and the charter is also not very concrete about what to expect, besides motivating the needed interfaces with the need for in-network security function. However, if there is nothing security specific about this, what's the difference to the usually control plane architecture as usually deployed with the use of NETCONF? And I am actually wondering if this is the right wg to write such a document. Further, I would at least have expected that this framework mandates for high control plan security given we are talking about the configuration and deployment of security function. However, it does not. It does rarely provide any concrete recommendation here, and basically leaves the door open to used these interfaces without authentication which I think is not acceptable.
-2: If no 2119 keywords are used, please remove the boilerplate. But if you do need to keep it, please use the updated boilerplate from 8174, since there are a number of lower case versions of 2119 keywords. -6.2: first bullet: I am always worried about text advising that "closed environments" have lower security requirements. That has proven false so many times we really shouldn't be encouraging it. This is especially worrisome since the first paragraph of section 11 talks about the importance of "trustworthy, robust, and fully secured access".
(1) I think there are some errors in Table 1, or perhaps there are just formatting issues that have me confused. It looks like TCP, SCTP, DCCP, UDP, and HTTP are listed under Layer 3. I can't tell if there is meant to be a difference between header fields separated by slashes versus those separated on different lines. There seems to be an extra column in front of the HTTP fields -- what does that signify? Why is TRAM profile in particular included as an example here? (2) Tables 2-4 also seem to be specified in a significant amount of detail, given that context and actions themselves are defined in detail in a different individual draft. This makes it hard to understand the implications of some of the fields. E.g., the "GPS coords" field -- whose GPS coords does this refer to? It seems like the fields in these tables either need to be explained more, or they should be removed. (3) I'm not going to stand in the way of publication but it's not clear to me why this document needs to be an RFC. Much of the content seems like a generic narrative that describes how NSFs could work but doesn't really lay out any concrete constraints about how they should work that would lead to greater interoperability.
I am not sure what the "addr" field in the Packet Content Matching Capability Index for IPv6 means (i.e. what protocol field it corresponds to) and I think it should be clarified.
As Alissa mentioned in her Ballot, the long-term archival value of this draft is not clear to me either. There are some places where it is not clear what the intent of the document is wrt the references; are they examples, recommendations or do they represent a stronger pillar in the i2nsf work. Just to highlight one of them: I’m not sure what is the intent with rfc5575 (Dissemination of Flow Specification Rules) is in 9.2. I’m confused because the reference is Normative, but the text sounds as if FlowSpec was an example: 9.2. Registration Categories Developers can register their NSFs using Packet Content Match categories. The IDR (Inter-Domain Routing) Flow Specification [RFC5575] has specified 12 different packet header matching types. More packet content matching types have been proposed in the IDR WG. I2NSF should re-use the packet matching types being specified as much as possible. More matching types might be added for Flow-based NSFS. Tables 1-4 below list the applicable packet content categories that can be potentially used as packet matching types by Flow-based NSFs: Also, the tables present categories that go beyond what FlowSpec covers. Where does the other information come from? Is there work that can reused there? What about IPFIX (that seems more appropriate than FlowSpec)? To be clear, I like very much the fact that the text advocates for reuse. It is just not clear what the expectation is with regards to rfc5575 or other proposed work in the idr WG. Is the expectation that the matching types be used in i2nsf systems? What about other related extensions that may be developed in idr, are there specific requirements or considerations that the idr WG should take into account? From the archive, it looks like idr hasn’t reviewed (or been notified of) this document… Note that if the mention of rfc5575 is just an example, then I think some of the text could be made clearer (and the reference should be Informative).