Subject: Re: [I2nsf] Calling for reviews of draft-ietf-i2nsf-problem-and-use-cases-06

From: "Dave Qi (BLOOMBERG/ 731 LEX)" <[email-masked]>
Date: Thu, 5 Jan 2017 23:54:32 -0000

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-masked] At: 12/26/16 12:12:50
To: [email-masked], [email-masked]
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-masked]] On Behalf Of Linda Dunbar
Sent: 08 December 2016 18:35
To: [email-masked]
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-masked]  list.
 
Regards,
 
Linda and Adrian
          _______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Jan 2017 07:28:31 -0500

Dave:

Thank you for your comments.  I’ll work with my co-authors to address these comments. 

Sue

From: Dave Qi (BLOOMBERG/ 731 LEX) [mailto:[email-masked]] 
Sent: Thursday, January 5, 2017 6:55 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re:[I2nsf] Calling for reviews of draft-ietf-i2nsf-problem-and-use-cases-06

Hey Adrian/Linda/Sue,

Best,

Dave

"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 <https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-06#ref-I-D.ietf-opsawg-firewalls> ]) does not mean that a network is
protected. "

"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 <https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-06#ref-I-D.ietf-opsawg-firewalls> ]) does not mean necessarily that the network is protected for certain. "

comment:

 <https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-06#section-3.5> 

4.1. Basic Framework

comment: distribute

correct execution"

 <https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-06#section-4.4> "Customers may require validating NSF availability, provenance, and execution."

 <https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-06#section-4.4> 

4.4 <https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-06#section-4.4> . Preventing Distributed DoS, Malware and Botnet attacks

comment:

5 <https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-06#section-5> . Management Considerations

o Signaling, and"

comment:

 

Hey working group,

Thanks!

Adrian

Dear all,

Regards,

Linda and Adrian