Interface to Network Security Functions
charter-ietf-i2nsf-01

[Ballot comment]
Worth a follow up, at least.

Disclaimer: I have not attended the BOF, neither followed the mailing list, and not read any documents.

- "Other aspects of NSFs, such as device or network provisioning and
configuration, are out of scope."

If I take this simple architecture:

application
    |
                controller
|    |    |
              NSF  NSF  NSF
|    |    |  |  |  |
                Network

Is this your way to say that you want to standardize the north bound interface of a controller and/or NSF?
I believe the charter should clearly mention which interface(s) I2NSF wants to specify.
For my information, I guess that:
1. the NSF south bound interfaces would remain proprietary
2. the NSF vendors will not open their full APIs
Am I right?

- "The goal of I2NSF is to define a set of software interfaces and data models for
controlling and monitoring aspects of physical and virtual NSFs.".

"I2NSF will focus on flow-based NSFs that provide
treatment to packets/flows, such as Intrusion Protection/Detection System
(IPS/IDS), Web filtering, flow filtering, deep packet inspection, or pattern
matching and remediation."

Can you provide an example of "controlling and monitoring".
Is this about: starting up, monitoring, and shutting down a virtualized N(S)F?
Or more such as: this flow should be redirected to this IPS (a-la SFC)?
Or more such as: this traffic/flow should be inspected by IPS

Discussing with Kathleen, it seems all of them. It was not too clear to me.

-
A lot of architectural components for a charter:
I2NSF Capability Layer, I2NSF Service Layer, Simple Service Layer
And you lost me with:
    o Only the Simple Service Layer policies that are modeled as closely as
possible on the Capability Layer are within the scope.  Such a Simple Service
Layer will enable a security controller to handle issues like multi-tenancy and
the choice between available NSFs for a given policy.

This goes back to my previous point

- Let's talk about the chance of success of this potential WG. I'll trust Kathleen's judgment here. However let me share my thoughts: With this type of charter, the IETF moves out of its comfort zone, and enters the territory where (opensource) code will prevail versus consensus-based standards that take too long to be produced. So the message behind the last paragraph is important.

[Ballot comment]

I think this is fine to go ahead. I do have some comments,
roughly in order of importance (but none being that
important):

- The capability vs. service "layer" thing is still not
clear to me as written, and I suspect those may just not
be the best terms, but I'm ok that it is considered clear
enough to those who want to participate that it'll work or
they'll need to fix this as they go. (I suspect the
latter, but am often wrong:-)

- The charter says "vendor" too often when it ought also
include open-source technologies - not every NSF provider
has to be for-profit.  For example in para1 maybe s/from
different vendors/from different vendors or open-source
technologies/ but a general pass for that would be good
maybe trying s/vendor/NSF developer/ or something.

- 1st sentence: should "and to block" be "or to block"?

- I like the last para.

- (nit) 2nd sentence introduces network security services
as being things that can be enforced by an NSF.  That's
probably ok, but could maybe be confusing for someone not
used to the service/mechanism distinction commonly used in
security. (So I'm not sure if that's ok or not since it is
clear enough for me.)

[Ballot comment]
I concur with Barry's comments about the time limit.

The following sentence sets important context, please consider moving it earlier in the charter:

"As there are many different security vendors supporting different features and
functions on their devices, I2NSF will focus on flow-based NSFs that provide
treatment to packets/flows, such as Intrusion Protection/Detection System
(IPS/IDS), Web filtering, flow filtering, deep packet inspection, or pattern
matching and remediation."

Is the capitalization of Simple Service Layer significant? That is, is it a named thing?

The deliverables seem overly prescriptive about document structure. (e.g. a "single document covering use cases..." instead of "Use cases...")

"The working group will communicate with external SDOs like ETSI NFV" sounds pretty open ended.

[Ballot comment]
The substance of the charter seems fine to me.  I just have some editorial comments.

In the first sentence, I think you mean to change "and" to "or" -- that is, one NSF does at least one of the things listed, not all of them.

In the second sentence, I don't know what it means for a *function* to be "consumed".  Can you find better wording than "consumed" for this?

Please fix the artifact of MS Word's "smart quoting" that's resulted in invalid characters ("???Functional Implementation???", "clients??? security policies", and "The I2NSF WG???s deliverables").

What are "Capability layer comments"?  (It's the "comments" part that I don't follow (so I guess it's good that translating to them is out of scope).)

We need a blank line after the bullet list (after the "Capability layer comments" sentence), or else the "However" sentence needs to be merged into the bullet.  (I'm thinking you mean the latter.)

I always prefer that "working group" be spelled out, so I suggest a global change of "WG" to "working group", but take that as Barry's preference and do as you like with it.

On "Working group re-charter or close: Charter time + 24 months", I'm generally not thrilled with that sort of statement.  If what you want to do is set a time limit, I think something more clear and explicit would be better.  Something like, "The working group must have the above deliverables completed within 24 months.  The responsible AD will close the working group at that time if they are not completed or close to completion.  The working group may be closed earlier if substantial progress is not being made."  If something like that isn't what's meant, then what *is* meant?

Added charter milestone "All early drafts to IESG for publication (if WG decided to proceed): use cases, problem statement, and gap analysis document; framework document; information model requirements for extensions to protocols document; examination of existing secure communication mechanisms document", due April 2017

Added charter milestone "WG decides whether to progress adopted drafts for publication as RFCs (use cases, framework, information model, and examination of existing secure communication mechanisms) ", due August 2016