Re: [Nsaas] 答复: Existing work, other things

[Linda Dunbar <[e-mail]>]

Melinda, 

Thanks for the suggested wording for IETF. 
Answers to your other questions are inserted below:

-----Original Message-----
From: Melinda Shore [mailto:[e-mail]] 
Sent: Tuesday, August 12, 2014 11:20 AM
To: Linda Dunbar; [e-mail]
Subject: Re: [Nsaas] 答复: Existing work, other things

I'm finding the discussion to be a little bit difficult to follow, to be honest.  Maybe it would be helpful to break things down
point-by-point:

1) The IETF has had considerable experience standardizing
   protocols between some sort of agent or controller and a
   network security device.  These have largely been
   unsuccessful, in the sense that they haven't been implemented
   and deployed.  I think any new effort in this area needs
   to make a case for why it will be successful, given that
   history.

[Linda] I've seen IETF work on general control <-> agent, but not specifically to Security functions, like FW policies, negotiations, and validations of security functions that are not physically located in the customer premises but accessed via remotely. 
There are many network functions being deployed and new ones are popping up with business and application demands. It is difficult specify concrete protocols for all network functions. Just to specify FW files alone is a big task. 

NSaaS focuses on the network security related functions because the wide acceptance of security functions that are not running on customer/enterprise premises. Numerous security vendors are now leveraging cloud based models to deliver security solutions. This shift has occurred for a variety of reasons including greater economies of scale, streamlined delivery mechanisms, and the demand of business and applications for more sophisticated security functions that they do not have. Consumers, enterprise clients as well as applications are embracing the business model of requesting for security functions that do not run on their own premises on demand, also known as Security as a Service.


2) If OpenStack is producing work that's being implemented,
   that's a good thing.  It is unclear to me why you would
   bring work "fixing" shortcomings in OpenStack to the IETF,
   rather than to OpenStack

[Linda] Apology for my improper wording. I didn't mean to "fix shortcomings of OpenStack". I want to advocate a productive eco-system for IETF to be plugged in to this uptrend Open Source initiatives in our industry. IETF can play a very active role in this initiative, e.g. leveraging its experience in specifying comprehensive specification that can be used as input to Open Source communities. 



3) I'm not at all clear on why this work is not being discussed
   in the context of sfc, while we're at it.  Why would it not
   fit there - that is to say, why is it a different problem?

[Linda] SFC doesn't cover in-depth specification (e.g. rules for the requested FW) for clients to request its needed functions. In SFC, FW function is a black box, that is treated in same way as Video Optimization function. SFC doesn't cover the negotiation part, e.g. Client needs Rule x/y/z for FW, but the Provider can only offer x/z. 

 
Melinda