Summary: Has a DISCUSS. Needs 8 more YES or NO OBJECTION positions to pass.
This document should be informational. I don't see any reason that this document must be cited normatively by all following document of this wg (as indicated in the shepherd write-up) and even if so that does not justify publication as Standards track if the information in the document is only informational.
As soon as my discuss is resolved I will change to 'Abstain' as I don't see value in the publication of this document. I can see that this document was useful for discussion in the working group but I don't know why it needs to be published as RFC. Also there is quite some redundancy everywhere in the document aa well as between the problem statement and use case part. Spelling out requirements for the protocol design based on the analysis of these problems and use cases (which was already a bit attempted from time to time in the doc) would have been more useful but does still not have an archivable value that justifies publication as RFC in the IETF stream (indicating IETF consensus).
Similar to other Abstains, I won't block publication but question the value, especially the current version to be published at this time. The document rambles on descriptions and it is not concise on the problem to be addressed by i2nsf. I recommend holding off on publication until it can be fine tuned, it currently appears to be a cut and paste of many documents. Agree with others the document should be Informational, not Standards track. Examples, section 5 seems to summarize that i2nsf will only focus on policy provisioning. Yet, section 3.4 discusses capability negotiation and 3.1.2 discusses monitoring mechanisms and execution status of NSFs capabilities. And other sections also infer much more, describing expectations of security controller functionality. There are several rather overzealous claims: Section 4.4 "botnet attacks could be easily prevented by provisioning security policies using the i2nsf..interface" and section 4.5 "security controller would keep track of ..if there is any policy violation ..proof..in full compliance with the required regulations". Several sentences don't parse e.g. "thereby raising concerns about the ability of SDN computation logic to send security policy-provisioning information to the participating NSFs".
I agree with Alvaro and Mirja.
Agree with my Abstaining co-ADs and don't think this document should be published on the Standards track but I will not stand in the way of publication.
I don't have any problem with this document per se, but it's a little odd how it's written in a vacuum as if there weren't already technologies which did a lot of the things you are talking about here (e.g., YANG) and which the WG intends to use. I think this document would be a lot stronger if it didn't act as if the WG was agnostic and instead called out what solutions the WG intends to adopt for these. I'm also somewhat surprised this is being advanced as Standards Track, given that it doesn't have any normative content, and becaus ehte writeup says that there isn't commitment to implement this. I won't hold a DISCUSS on this, but I would suggest it be Informational. S 2. Flow-based NSF: An NSF which inspects network flows according to a security policy. Flow-based security also means that packets are inspected in the order they are received, This seems over-specific, because sometimes firewalls and the like will store packets so that it can re-assemble them, in which case it inspects them in logical not time order. S 3.1.7. Different policies might need different signatures or profiles. Today, the construction and use of black list databases can be a win-win strategy for all parties involved. Well, except for attackers. They are involved. S 3.1.9; bullet 3. Symmetric keys and group keys are not the same type of category, so I can't read this section. What are you trying to say here? S 3.5. "xamine" and "scnearios" are misspelled. S 3.6. ToR seems to be undefined. Figure 3. I think this dotted circle-thing is intended to tell me that the operator controls the stuff inside the circle, but I'm not sure. Maybe some labels would help.
[Mirja beat me to the DISCUSS; FWIW, I completely agree that, if published, this document should not be in the Standards Track.] Because this document only provides background on the problem space and some use cases, I don't think it has the long standing value to be published as an RFC (of any maturity level). Having a clear understanding of the problem and of the use cases is important for the eventual development of a solution, but in this case no specific path is clearly marked: the language includes a lot of "may be required/need/etc" not resulting in a strong basis to build a solution. I know that the i2nsf Charter gave the WG the option to not publish this document, and that it is being published anyway...so I won't stand in the way of publication and am ABSTAINing instead.