Hey Adrian/Linda/Sue, Sorry for the belated response.
Yes. I read it and it seems to be ready except a couple of minor things listed below... Best, Dave ----------------------------- 3.1.2. Diverse Interfaces to Control and Monitor NSFs "A challenge for monitoring is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected. " comment: not sure it meant by "an NSF cannot monitor what it cannot view." May be should be something like: "A challenge for security monitoring is the lack of visibility and verifiability: that one can't effectively monitor NSFs if they are not easily accessible and verifiable for execution. Therefore, traditional method of enabling a security function on a network (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean necessarily that the network is protected for certain. " 3.4. Software-Defined Networks "...thereby raising concerns about the ability of making sure the SDN computation logic is entitled to send security policy-provisioning information to the participating NSFs, " comment: probably should be changed to "...thereby raising concerns about the ability of the SDN computation logic to send security policy-provisioning information to the participating NSFs, " 3.5. Lack of Standard Interface to Inject Feedback to NSF comment: I found the whole section is off-target. The title says lack of standard feedback interface. but the text describes lack of standard security profile exchange interface among enterprises. Cyper Threat Alliance (CA) should be (CTA) 4.1. Basic Framework "Interface 2 is used for interacting with NSFs according to commands (e.g. enact policy and distribuge)," comment: distribute "Customers may require validating NSF availability, provenance, and correct execution" comment: a little confusing... may be it should be changed to "Customers may require validating NSF availability, provenance, and execution." 4.4. Preventing Distributed DoS, Malware and Botnet attacks "the I2NSF framework should provide client-side interfaces that are use case-independent and technology-agnostic." comment: I am not sure "technology-agnostic" is the right word. May be we should say "the I2NSF framework should provide client-side interfaces that are generic and language independent (or data model independent)". 5. Management Considerations "Management of NSFs usually include the following: o Signaling, and" comment: "Signaling" is pretty vague. May be it meant "Orchestrating"? From: [email protected] At: 12/26/16 12:12:50 To: [email protected], [email protected] Subject: Re:[I2nsf] Calling for reviews of draft-ietf-i2nsf-problem-and-use-cases-06 Hey working group, I know you are all off drinking eggnog and toasting things on open fires while he snow piles up around your windows and pretty lights twinkle in the tree, but it would be really good if a few more of you could spend an hour or two reading and commenting on this draft as it goes through last call. Thanks! Adrian From: I2nsf [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: 08 December 2016 18:35 To: [email protected] Subject: [I2nsf] WGLC for draft-ietf-i2nsf-problem-and-use-cases-06 Dear all, After many rounds of editing, the authors finally believe the draft is ready. We will start of the Working Group Last Call (WGLC) for draft-ietf-i2nsf-problem-and-use-cases-06 The WGLC lasts for 3 weeks and will end Dec 29 at 10 pm PDT. Please send your comments and reviews to the [email protected] list. Regards, Linda and Adrian _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
