Rakesh:
My understanding is that RFC4949 that Bob quoted is the IETF general definition. Let me answer your questions. Do we just make sure that definition is same across all IETF work no matter how outdated? We believe that RFC4949 is not outdated. We need to provide feedback to the NETMOD that draft-ietf-netmod-acl-model does not reference RFC4949, and is providing a change. Do we want to make sure that it aligns with where the networking industry is? Does the network industry have a common de-facto definition? Is it different than RFC4949? Cisco CLI has one way of doing ACLs, and Juniper’s CLI could be viewed to have a separate one. Perhaps you can provide additional information why you think RFC4949 is not the way the industry is going? Do we want to make sure that it aligns with the security work we are doing in I2NSF? IMHO, I2NSF wants to make sure the draft-ietf-netmod-acl-model aligns with I2NSF so that we can utilize the Yang models to minimize code redundancy in the code. Cheerily, Sue Hares From: Rakesh Kumar [mailto:[email protected]] Sent: Tuesday, September 13, 2016 1:01 AM To: John Strassner; Linda Dunbar; DIEGO LOPEZ GARCIA; Xialiang (Frank) Cc: [email protected]; Susan Hares; Rakesh Kumar Subject: Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model Hi Linda, As evident (https://en.wikipedia.org/wiki/Access_control_list), the ACL has different meaning to different folks (IT, Network). John rightly pointed out that originally it meant some kind of permission but networking industry adopted this to associate with packet filtering as you pointed out. History aside, the ACL have evolved dramatically over the years for various reasons: · Vendor want to give admin control over operational state of the networking device (override protocols or control plane) · SDN controller use ACL to configure operational state instead of running control plane · Feature (forwarding/Security/QoS/Monitoring) innovation/differentiations by vendors In my opinion, ACL can be lot more than filtering or permission (of course each vendor has different capability) but I am not sure what is our (I2NSF) specific goal behind this discussion. Do we just make sure that definition is same across all IETF work no matter how outdated? Do we want to make sure that it aligns with where the networking industry is? Do we want to make sure that it aligns with the security work we are doing in I2NSF? Thanks & Regards, Rakesh From: I2nsf <[email protected]> on behalf of John Strassner <[email protected]> Date: Monday, September 12, 2016 at 5:31 PM To: Linda Dunbar <[email protected]>, John Strassner <[email protected]>, DIEGO LOPEZ GARCIA <[email protected]>, "Xialiang (Frank)" <[email protected]> Cc: "[email protected]" <[email protected]>, Susan Hares <[email protected]> Subject: Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model Hi Linda, My vote is NO. With all due respect, RFC4949 predates the acl model by almost 7 years. Furthermore, ACLs may or may not **filter** traffic. The roots of ACLs go much farther back (at least to 1997 that I can find) and, fundamentally, are permissions. A permission is not the same as filtering. Finally, we would then have to define ACEs, and not all ACL models have ACEs. regards, John On Mon, Sep 12, 2016 at 10:06 AM, Linda Dunbar <[email protected]> wrote: John, et al, The “ietf-netmod-acl-model” has “ACL” defined as: An ACL is an ordered set of rules that is used to filter traffic on a networking device. Each rule is represented by an Access Control Entry (ACE). The “draft-ietf-i2nsf-terminology-01” has ACL as: ACL (Acess Control List): This is a mechanism that implements access control for a system resource by enumerating the system entities that are permitted to access the resource and stating, either implicitly or explicitly, the access modes granted to each entity [RFC4949]. A YANG description is defined in [I-D.ietf-netmod-acl-model]. Can we make I2NSF’s ACL definition consistent with the ““ietf-netmod-acl-model”? Thanks, Linda -- regards, John
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
