> On Feb 4, 2015:5:22 PM, at 5:22 PM, Linda Dunbar <[email protected]> 
> wrote:
> 
> Tom, 
> 
> Will those existing WGs you mentioned also do the following?
> 
> - a standard interface to express, monitor, and verify the security policies 
> on distributed security functions that may be running on different premises.
> 
> This layer will leverage the existing protocols in RESTconf, AAA, SACM, and 
> security policy expression using Role Based Access Control (RBAC), Mandatory 
> Access Control (MAC), or Attribute-based access control (ABAC).

        As I've mentioned before, Yang models for any of these things can and 
are underway today.
I couldn't agree more that they are not needed. 

        However, regarding the other stuff, I invite you to look at just two 
examples of what is going on outside of the IETF.  
These are real implementations documented publicly in some cases such as 
Comcast presented at the last Openstack summit.

        https://wiki.opendaylight.org/view/Network_Intent_Composition:Main

        https://wiki.openstack.org/wiki/Congress

        Based on that, I really don't see any need to do any of this work in a 
new WG. Not only will it be a duplicate of a lot 
of actual work already being done elsewhere, as far as I can tell, it will not 
be doing so based on any real implementations/deployments 
(i.e.: "running code" from the IETF's mantra). Or have I missed something?

> Those WGs charters don't have those objectives. 
        
        That doesn't mean they couldn't be added to existing ones. I'd also bet 
that is easier than lifting off a new WG 
to accomplish these goals and will be more efficient as we won't be adding the 
extra management/processing overhead to
the already heavy load at the IETF.  

        --Tom



> 
> Thanks, Linda
> 
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email protected]] 
> Sent: Wednesday, February 04, 2015 2:37 PM
> To: Romascanu, Dan (Dan)
> Cc: Linda Dunbar; Russ White; [email protected]; Susan Hares; [email protected]; 
> [email protected]
> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF
> 
> 
>       They certainly could, without the added management overhead of a new WG.
> 
>       --Tom
> 
>> On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) 
>> <[email protected]> wrote:
>> 
>> Tom,
>> 
>> I2NSF in its most recent (and better focused) charter includes IMs and DMs 
>> for firewalls and IDSs, as well as a framework to manage virtualized 
>> security services. Does LIME or other WG in the IETF do any of these? 
>> 
>> Regards,
>> 
>> Dan
>> 
>> 
>>> -----Original Message-----
>>> From: I2nsf [mailto:[email protected]] On Behalf Of Thomas D. 
>>> Nadeau
>>> Sent: Wednesday, February 04, 2015 9:50 PM
>>> To: Linda Dunbar
>>> Cc: Russ White; [email protected]; Susan Hares; [email protected]; 
>>> [email protected]
>>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF
>>> 
>>> 
>>>> On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar
>>> <[email protected]> wrote:
>>>> 
>>>> 
>>>> Thomas,
>>>> 
>>>> Comments inserted below:
>>>> 
>>>> -----Original Message-----
>>>> From: I2nsf [mailto:[email protected]] On Behalf Of Thomas D.
>>> Nadeau
>>>> Sent: Wednesday, February 04, 2015 10:37 AM
>>>> To: Linda Dunbar
>>>> Cc: Russ White; [email protected]; [email protected]; Susan Hares; 
>>>> [email protected]
>>>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF
>>>> 
>>>> 
>>>>> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar
>>> <[email protected]> wrote:
>>>>> 
>>>>> Russ,
>>>>> 
>>>>> Thank you very much for the suggestion of framing in terms of services.
>>> What do you think with the following changes to the I2NSF charter 
>>> with your suggestions added?
>>>>> 
>>>>> In a nutshell, The Interface to vNSF (I2NSF) allows clients to 
>>>>> communicate
>>> their specific security policies (request/monitor/report) to security 
>>> functions.
>>> I2NSF will specify a vNSF framework, requirements for programmatic
>>> interface to vNSF devices (configuration and dynamic programmatic)   , and
>>> Information and Data models for security functions' Operation, 
>>> Administration, Maintenance and Provisioning (OAM).  The information 
>>> models will include the following security functions:
>>>> 
>>>>    Why wouldn't you do the models for those OAM functions where
>>> those functions are modeled already?  I don't see the need for a 
>>> special WG that creates a subset of models that can done elsewhere 
>>> like in LIME, or the Routing Area groups that are already chartered to do 
>>> this stuff.
>>>> 
>>>> [Linda] LIME addresses OAM for network layer, connectivity 
>>>> (link/port)
>>> failures, end to end performances measurement, whereas I2NSF is for 
>>> security policies to be enforced by distributed (virtual) network 
>>> security functions (vNSF). I2NSF provides a standard interface to 
>>> express, monitor, and manage the security policies across distributed 
>>> security functions that may be running on different premises.
>>> 
>>> [TOM] The salient point I have been trying to make is that i2nsf does 
>>> not exist; LIME does. Why not just do it there (and other existing 
>>> places in the IETF)?  We seem to be working REALLY hard here to make 
>>> up reasons why we need to form a new working group. I'd contend that 
>>> it is not needed and that the management overhead + other overhead of 
>>> reviewing/processing documents like a new framework, requirements, 
>>> etc... will unnecessarily spend precious IETF resources.
>>> 
>>>     --Tom
>>> 
>>> 
>>>>    This leaves just doing requirements and a framework for this
>>> proposed group, which without clear goals to build things from is a 
>>> WG looking for a reason to exist rather than the other way around.
>>>> 
>>>>    --Tom
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> * Firewall
>>>>>   including various services associated with FW, such as stateful or
>>> deep packet inspection,  packet/flow/stream filtering and redirect 
>>> (remote and local), etc
>>>>> 
>>>>> * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
>>>>>   Including intrusion detection (flow/stream pattern matching)
>>>>> 
>>>>> 
>>>>> Linda
>>>>> 
>>>>> -----Original Message-----
>>>>> From: i2rs [mailto:[email protected]] On Behalf Of Russ White
>>>>> Sent: Tuesday, February 03, 2015 7:35 AM
>>>>> To: 'Susan Hares'; Linda Dunbar; [email protected]
>>>>> Cc: [email protected]; [email protected]
>>>>> Subject: Re: [i2rs] revised charter for I2NSF
>>>>> 
>>>>> 
>>>>> Interesting concept. One thought that might be helpful --
>>>>> 
>>>>>> *         Firewall
>>>>>> *         DDOS/Anti-DOS
>>>>>> *         Intrusion Detection System/ Intrusion Prevention System
>>>>>> (IDS/IPS)
>>>>>> *         Access control/Authorization/Authentication
>>>>> 
>>>>> I think I would try to frame things in terms of services, rather 
>>>>> than
>>> devices, or a mix of the two. For instance -- what does a "firewall" really 
>>> do?
>>> Stateful packet inspection, deep packet inspection, and... ?? So 
>>> maybe a list something like this might make sense -- (and remember, 
>>> this is brainstorming, nothing more) --
>>>>> 
>>>>> - Stateful packet inspection
>>>>> - Deep packet inspection
>>>>> - Packet/flow/stream filtering (remote and local)
>>>>> - Packet/flow/stream redirect (remote and local)
>>>>> - Intrusion detection (or perhaps flow/stream pattern matching?)
>>>>> - AAA
>>>>> 
>>>>> Don't know if this is a useful line of thought or not.
>>>>> 
>>>>> :-)
>>>>> 
>>>>> Russ
>>>>> 
>>>>> _______________________________________________
>>>>> i2rs mailing list
>>>>> [email protected]
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=AwICAg&c=BFpWQw8bsuKpl1S
>>> giZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kNB
>>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=YlZUo4btDn8UA3sAV2F_rWaL
>>> TDFHlxo1ys_wiueV8NI&e=
>>>>> 
>>>>> _______________________________________________
>>>>> i2rs mailing list
>>>>> [email protected]
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=AwICAg&c=BFpWQw8bsuKpl1S
>>> giZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kNB
>>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=YlZUo4btDn8UA3sAV2F_rWaL
>>> TDFHlxo1ys_wiueV8NI&e=
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> I2nsf mailing list
>>>> [email protected]
>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwICAg&c=BFpWQw8bsuKpl1
>>> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kN
>>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=Aag4Z_qnWDkR36ft_q-
>>> U7rpbPenEFmJgJ11F9yjW29E&e=
>>>> 
>>> 
>>> _______________________________________________
>>> I2nsf mailing list
>>> [email protected]
>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwICAg&c=BFpWQw8bsuKpl1
>>> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ZXR0kN
>>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=Aag4Z_qnWDkR36ft_q-
>>> U7rpbPenEFmJgJ11F9yjW29E&e=
>> 
> 
> 

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to