Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Eliot Lear]

Hurry?!  Please look at the history of this draft.


On 11/18/16 3:27 PM, David Bannister wrote:
> If you are in a hurry use your vendor model.
>
> On Fri, Nov 18, 2016 at 11:24 PM Eliot Lear  > wrote:
>
> It's already useful to me.  And we've seen other people say it is
> useful to them.  If you need something specific, say so now
> please, but otherwise let's please move along.
>
> Eliot
>
>
> On 11/18/16 3:07 PM, David Bannister wrote:
>> This draft should not move forward, it needs more work to be
>> useful. Will be working with Dean next week to fix things up.
>>
>> On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear > > wrote:
>>
>> Dean and friends,
>>
>> I'd just like to add one additional point.  This draft has
>> been in numerous forms of WGLC for a while now.   Can we
>> please agree that as a proposed standard we have passed the
>> point where perfect is the enemy of good?  Some of us need
>> this work finished.
>>
>> Thanks,
>>
>> Eliot
>>
>>
>>
>>
>>
>> On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
>>> Hi Dean, 
>>> If you make this a list of heterogeneous IPv4 header fields,
>>> how will you constrain specification to only one field of
>>> each type? For example, one source address? Existing
>>> implementations do not support multiples and generate all
>>> permutations (given multiple specifications of each field)
>>> could be complex. 
>>> Thanks,
>>> Acee 
>>>
>>>
>>> From: netmod >> > on behalf of Dean
>>> Bogdanovic >
>>> Date: Tuesday, November 15, 2016 at 10:06 AM
>>> To: Kent Watsen >> >
>>> Cc: "netmod@ietf.org "
>>> >
>>> Subject: Re: [netmod] WG Last Call for
>>> draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)
>>>
>>> I have something that might delay WGLC, but found out an
>>> optimization which would help in the future
>>>
>>> In ietf-packet-fields.yang, example below
>>>
>>> grouping acl-ipv4-header-fields {
>>>description
>>>  "Fields in IPv4 header.";
>>>leaf destination-ipv4-network {
>>>  type inet:ipv4-prefix;
>>>  description
>>>"Destination IPv4 address prefix.";
>>>}
>>>leaf source-ipv4-network {
>>>  type inet:ipv4-prefix;
>>>  description
>>>"Source IPv4 address prefix.";
>>>}
>>>  }
>>>
>>> Instead of using "leaf" for "destination-ipv4-network"
>>> and "source-ipv4-network", "leaf-list" reduces the
>>> number of terms/ace needed.
>>>
>>> If we would agree with this change, then would propose
>>> one more 
>>>
>>> for mac-addresses, having the mask under the address
>>> itself look better in the data itself:
>>>
>>>   
>>> 01:01:01:00:00:00
>>> ff:ff:ff:00:00:00
>>>   
>>>
>>>   Or create a new type 'mac-address-prefix'.
>>>
>>>   This allows having matching multiple destinations to 1
>>> source, or multiple sources to 1 destination, if they
>>> cannot be easily combined into 1 entry.
>>>
>>>   
>>> 01:01:01:00:00:00
>>> ff:ff:ff:00:00:00
>>>   
>>>   
>>> 01:04:01:00:00:00
>>> ff:ff:ff:00:00:00
>>>   
>>>   
>>> 
>>>   
 On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic
 > wrote:

 Kent,

 Thank you for the answer
> On Nov 13, 2016, at 1:20 PM, Kent Watsen
> > wrote:
>
> Hi Dean,
>  
> > Don’t understand your question. What is the
> difference between system and user generated acls?
>  
> User-generated would be, for instance, configured via
> NETCONF or RESTCONF, whereas system-generated would be
> ACLs that get created by default.  For example, RFC
> 7223 has the top-level /interfaces-state to support
> system-generated interfaces (e.g., lo) so, when
> 

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Eliot Lear]

It's already useful to me.  And we've seen other people say it is useful
to them.  If you need something specific, say so now please, but
otherwise let's please move along.

Eliot


On 11/18/16 3:07 PM, David Bannister wrote:
> This draft should not move forward, it needs more work to be useful.
> Will be working with Dean next week to fix things up.
>
> On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear  > wrote:
>
> Dean and friends,
>
> I'd just like to add one additional point.  This draft has been in
> numerous forms of WGLC for a while now.   Can we please agree that
> as a proposed standard we have passed the point where perfect is
> the enemy of good?  Some of us need this work finished.
>
> Thanks,
>
> Eliot
>
>
>
>
>
> On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
>> Hi Dean, 
>> If you make this a list of heterogeneous IPv4 header fields, how
>> will you constrain specification to only one field of each type?
>> For example, one source address? Existing implementations do not
>> support multiples and generate all permutations (given multiple
>> specifications of each field) could be complex. 
>> Thanks,
>> Acee 
>>
>>
>> From: netmod > > on behalf of Dean Bogdanovic
>> >
>> Date: Tuesday, November 15, 2016 at 10:06 AM
>> To: Kent Watsen >
>> Cc: "netmod@ietf.org " > >
>> Subject: Re: [netmod] WG Last Call for
>> draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)
>>
>> I have something that might delay WGLC, but found out an
>> optimization which would help in the future
>>
>> In ietf-packet-fields.yang, example below
>>
>> grouping acl-ipv4-header-fields {
>>description
>>  "Fields in IPv4 header.";
>>leaf destination-ipv4-network {
>>  type inet:ipv4-prefix;
>>  description
>>"Destination IPv4 address prefix.";
>>}
>>leaf source-ipv4-network {
>>  type inet:ipv4-prefix;
>>  description
>>"Source IPv4 address prefix.";
>>}
>>  }
>>
>> Instead of using "leaf" for "destination-ipv4-network" and
>> "source-ipv4-network", "leaf-list" reduces the number of
>> terms/ace needed.
>>
>> If we would agree with this change, then would propose one more 
>>
>> for mac-addresses, having the mask under the address itself
>> look better in the data itself:
>>
>>   
>> 01:01:01:00:00:00
>> ff:ff:ff:00:00:00
>>   
>>
>>   Or create a new type 'mac-address-prefix'.
>>
>>   This allows having matching multiple destinations to 1
>> source, or multiple sources to 1 destination, if they cannot
>> be easily combined into 1 entry.
>>
>>   
>> 01:01:01:00:00:00
>> ff:ff:ff:00:00:00
>>   
>>   
>> 01:04:01:00:00:00
>> ff:ff:ff:00:00:00
>>   
>>   
>> 
>>   
>>> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic
>>> > wrote:
>>>
>>> Kent,
>>>
>>> Thank you for the answer
 On Nov 13, 2016, at 1:20 PM, Kent Watsen
 > wrote:

 Hi Dean,
  
 > Don’t understand your question. What is the difference between
 system and user generated acls?
  
 User-generated would be, for instance, configured via
 NETCONF or RESTCONF, whereas system-generated would be ACLs
 that get created by default.  For example, RFC 7223 has the
 top-level /interfaces-state to support system-generated
 interfaces (e.g., lo) so, when running `shows interfaces`,
 the result includes both configured and system-generated
 interfaces.   Makes sense?
>>>
>>> I understand now what you meant. Where I can see for the
>>> interfaces the use case you describe (for loopback and
>>> physical interfaces), for ACLs have much harder time to find
>>> an example use case where a system would generate an ACL.
>>> Maybe for a highly secure system would generate an ACL to
>>> deny all traffic to and from, except to access it via
>>> console when it comes up. Can you come with some other use
>>> cases? If we can find viable use cases, then yes, would say
>>> that reporting opstate for system generated ACLs is useful.
>>>
>>> Dean
>>>
  

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Eliot Lear]

Dean and friends,

I'd just like to add one additional point.  This draft has been in
numerous forms of WGLC for a while now.   Can we please agree that as a
proposed standard we have passed the point where perfect is the enemy of
good?  Some of us need this work finished.

Thanks,

Eliot





On 11/18/16 1:55 PM, Acee Lindem (acee) wrote:
> Hi Dean, 
> If you make this a list of heterogeneous IPv4 header fields, how will
> you constrain specification to only one field of each type? For
> example, one source address? Existing implementations do not support
> multiples and generate all permutations (given multiple specifications
> of each field) could be complex. 
> Thanks,
> Acee 
>
>
> From: netmod  > on behalf of Dean Bogdanovic
> >
> Date: Tuesday, November 15, 2016 at 10:06 AM
> To: Kent Watsen >
> Cc: "netmod@ietf.org "  >
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09
> (until Oct 27, 2016)
>
> I have something that might delay WGLC, but found out an
> optimization which would help in the future
>
> In ietf-packet-fields.yang, example below
>
> grouping acl-ipv4-header-fields {
>description
>  "Fields in IPv4 header.";
>leaf destination-ipv4-network {
>  type inet:ipv4-prefix;
>  description
>"Destination IPv4 address prefix.";
>}
>leaf source-ipv4-network {
>  type inet:ipv4-prefix;
>  description
>"Source IPv4 address prefix.";
>}
>  }
>
> Instead of using "leaf" for "destination-ipv4-network" and
> "source-ipv4-network", "leaf-list" reduces the number of terms/ace
> needed.
>
> If we would agree with this change, then would propose one more 
>
> for mac-addresses, having the mask under the address itself
> look better in the data itself:
>
>   
> 01:01:01:00:00:00
> ff:ff:ff:00:00:00
>   
>
>   Or create a new type 'mac-address-prefix'.
>
>   This allows having matching multiple destinations to 1 source,
> or multiple sources to 1 destination, if they cannot be easily
> combined into 1 entry.
>
>   
> 01:01:01:00:00:00
> ff:ff:ff:00:00:00
>   
>   
> 01:04:01:00:00:00
> ff:ff:ff:00:00:00
>   
>   
> 
>   
>> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic > > wrote:
>>
>> Kent,
>>
>> Thank you for the answer
>>> On Nov 13, 2016, at 1:20 PM, Kent Watsen >> > wrote:
>>>
>>> Hi Dean,
>>>  
>>> > Don’t understand your question. What is the difference between
>>> system and user generated acls?
>>>  
>>> User-generated would be, for instance, configured via NETCONF or
>>> RESTCONF, whereas system-generated would be ACLs that get
>>> created by default.  For example, RFC 7223 has the top-level
>>> /interfaces-state to support system-generated interfaces (e.g.,
>>> lo) so, when running `shows interfaces`, the result includes
>>> both configured and system-generated interfaces.   Makes sense?
>>
>> I understand now what you meant. Where I can see for the
>> interfaces the use case you describe (for loopback and physical
>> interfaces), for ACLs have much harder time to find an example
>> use case where a system would generate an ACL. Maybe for a highly
>> secure system would generate an ACL to deny all traffic to and
>> from, except to access it via console when it comes up. Can you
>> come with some other use cases? If we can find viable use cases,
>> then yes, would say that reporting opstate for system generated
>> ACLs is useful.
>>
>> Dean
>>
>>>  
>>> Thanks,
>>> Kent
>>>  
>>> *From: *Dean Bogdanovic >> >
>>> *Date: *Friday, November 11, 2016 at 3:45 PM
>>> *To: *Kent Watsen >
>>> *Cc: *"netmod@ietf.org "
>>> >
>>> *Subject: *Re: [netmod] WG Last Call for
>>> draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)
>>>  
>>>  
 On Oct 29, 2016, at 4:01 AM, Kent Watsen > wrote:
  
 The last call period for this draft has ended.   Thank you to
 all that responded.  Given the responses received, my co-chair
 and I believe that the draft is ready to move forward.  I will
 begin the shepherd write-up shortly.
 In parallel, prompted by a conversation I had this morning, I’m
 wondering 

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-08 (until Oct 5, 2016)

[Mahesh Jethanandani]

> On Nov 13, 2016, at 11:02 AM, Dean Bogdanovic  wrote:
> 
> Adrian,
> 
> Sorry for not replying earlier. Your email fell through the cracks. 
> 
>> On Sep 21, 2016, at 5:55 PM, Adrian Pan > > wrote:
>> 
>> I have reviewed draft-ietf-netmod-acl-model-08 and I am considering to 
>> implement the data model in the draft, while I found below issue:
>> - Operator is able to configure the matches of ace different from the 
>> acl-type, i.e ace configured with ipv6 matches while the “acl-type” is 
>> configured as ipv4 in the acl, this is not aligned with the model design 
>> intention.
> 
> The acl-type provides implicit specification of the match criteria. Authors 
> wanted to enable support for mixed type acl (example mac and ip) in the same 
> list. And let the vendors determine based on their platform and what is 
> supported how to implement the model.

I do not understand “implicit specification of the match criteria". Say the 
acl-type is specified as ipv6, and the user configures a ipv4 address in the 
ACL, how does it help the platform?

I agree with Adrian that a more intuitive use of the acl-type would be to check 
whether the address being configured matches the type and reject the 
configuration if it does not.

> 
> Dean
> 
>>  
>> Thanks
>> Adrian
>> From: netmod [mailto:netmod-boun...@ietf.org 
>> ] On Behalf Of Kent Watsen
>> Sent: Wednesday, September 21, 2016 4:46 AM
>> To: netmod@ietf.org 
>> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-08 (until Oct 
>> 5, 2016)
>>  
>>  
>> This is a notice to start a two-week NETMOD WG last call for the document:
>>  
>>Network Access Control List (ACL) YANG Data Model
>>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-08 
>> 
>>  
>> Please indicate your support or concerns by Wednesday, October 5, 2016.
>>  
>> We are particularly interested in statements of the form:
>>   * I have reviewed draft-ietf-netmod-acl-model-08 and found no issues.
>>   * I have reviewed draft-ietf-netmod-acl-model-08 and found the following 
>> issues: ...
>>  
>> As well as:
>>  * I have implemented the data model in draft-ietf-netmod-acl-model-08.
>>   * I am implementing the data model in draft-ietf-netmod-acl-model-08.
>>   * I am considering to implement the data model in 
>> draft-ietf-netmod-acl-model-08.
>>   * I am not considering to implement the data model in 
>> draft-ietf-netmod-acl-model-08.
>>  
>> Thank you,
>> NETMOD WG Chairs
>>  
>>  
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod 
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod