Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases
draft-ietf-i2nsf-problem-and-use-cases-16

I agree with Alvaro and Mirja.

[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.

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 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.

I don't see value in the publication of this document in the RFC series. 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 as 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).

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 appreciate the work that has gone into the document for the exercise of defining the problem and use-cases, however I question the value of publishing this document as an RFC, but I will not block its path should other ADs consider it of use. I am taking an abstain position.