Re: [I2nsf] Alissa Cooper's No Objection on draft-ietf-i2nsf-framework-08: (with COMMENT)

[Linda Dunbar <[e-mail]>]

Alissa,

Thank you very much for the comments to our draft.
Reply to your comments are inserted below:


-----Original Message-----
From: Alissa Cooper [mailto:[e-mail]]
Sent: Wednesday, October 25, 2017 3:48 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Adrian Farrel <[e-mail]>; Yoav Nir <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Alissa Cooper's No Objection on draft-ietf-i2nsf-framework-08: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-i2nsf-framework-08: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(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?

[Linda] Formatting issue. Will remove the "|" in the  HTTP field. The listed field in the registration is to "signify" that the NSF can support matching condition using the listed field.

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

[Linda] We have the option of putting those tables in the "draft-hyun-i2nsf-registration-interface-im". This section is to provide the guideline.


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

[Linda] The draft-ietf-i2nsf-framework describes the framework that glues together multiple detailed drafts describing different aspects of Interface to Network Security functions, such as   draft-ietf-i2nsf-capability-00,
draft-abad-i2nsf-sdn-ipsec-flow-protection-03, draft-hares-i2nsf-capability-data-model-04, draft-kim-i2nsf-nsf-facing-interface-data-model-03, etc.

In addition, several recent industry initiatives are referencing I2NSF to guide their next step work. Such as ONUG (Open Network User Group) Software Defined Security Services and Linux Foundation’s OSC (Open Security Controller).  This is one example that IETF is leading the industry.
Without publishing draft-ietf-i2nsf-framework, it is not easy for other industry initiatives to utilize the specifications (in many pieces) published by IETF.

Linda