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

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Nov 2016 23:35:54 +0000

Authors,

I’m hoping for a response regarding if there a need to support report opstate for system-generated ACLs?

Also, can you please respond to this older review: https://www.ietf.org/mail-archive/web/netmod/current/msg16812.html.

Thanks,
Kent (as shepherd)

From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Friday, October 28, 2016 at 3:01 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

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 about the YANG module’s use of the config false nodes ‘acl-oper-data’ and ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the same as the configured nodes?  - is there any need to support reporting opstate for system-generated acls?

Thanks,
Kent (as shepherd)

From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Thursday, October 13, 2016 at 5:05 PM
To: "[email-masked]" <[email-masked]>
Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 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-09

Please indicate your support or concerns by Thursday, October 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
  * I have reviewed draft-ietf-netmod-acl-model-09 and found the following issues: ...

As well as:
 * I have implemented the data model in draft-ietf-netmod-acl-model-09.
  * I am implementing the data model in draft-ietf-netmod-acl-model-09.
  * I am considering to implement the data model in draft-ietf-netmod-acl-model-09.
  * I am not considering to implement the data model in draft-ietf-netmod-acl-model-09.

Thank you,
NETMOD WG Chairs

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 11 Nov 2016 15:45:29 +0900

> On Oct 29, 2016, at 4:01 AM, Kent Watsen <[email-masked]> wrote:
> 
> In parallel, prompted by a conversation I had this morning, I’m wondering about the YANG module’s use of the config false nodes ‘acl-oper-data’ and ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the same as the configured nodes? 

Yes, they are. When the nodes are created, they are don’t have to be attached to an another object, like interface or RIB, etc, but they get operational state. Once attached, (to continue with the example) operational status of counters is changing. When detached from the interface, the last know counter is kept, until the ace is deleted. Same is for acl-oper-data.

> - is there any need to support reporting opstate for system-generated acts?

Don’t understand your question. What is the difference between system and user generated acls?

Dean

> 
> Thanks,
> Kent (as shepherd)
>  
>  
> From: netmod <[email-masked] <mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>                https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 <https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09>
>  
> _______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Kent Watsen <[email-masked]>
Date: Sun, 13 Nov 2016 04:20:11 +0000

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?

Thanks,
Kent

From: Dean Bogdanovic <[email-masked]>
Date: Friday, November 11, 2016 at 3:45 PM
To: Kent Watsen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Dean

Thanks,
Kent (as shepherd)

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 13, 2016 at 5:05 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

As well as:

Thank you,
NETMOD WG Chairs

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 14 Nov 2016 07:35:43 +0900

Kent,

Thank you for the answer
> On Nov 13, 2016, at 1:20 PM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Dean,
>  

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

>> On Oct 29, 2016, at 4:01 AM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 15 Nov 2016 10:06:53 +0900

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:

  <destination-mac-address>
    <address>01:01:01:00:00:00</address>
    <mask>ff:ff:ff:00:00:00</mask>
  </destination-mac-address>

  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.

  <destination-mac-address>
    <address>01:01:01:00:00:00</address>
    <mask>ff:ff:ff:00:00:00</mask>
  </destination-mac-address>
  <destination-mac-address>
    <address>01:04:01:00:00:00</address>
    <mask>ff:ff:ff:00:00:00</mask>
  </destination-mac-address>
  <source-mac-address>
    ....
  </source-mac-address>
> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic <[email-masked]> wrote:
> 
> Kent,
> 
> Thank you for the answer
>> On Nov 13, 2016, at 1:20 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Dean,
>>  
>> From: Dean Bogdanovic <[email-masked] <mailto:[email-masked]>>
>> To: Kent Watsen <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 18 Nov 2016 12:55:07 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 15, 2016 at 10:06 AM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>> wrote:

Kent,

Thank you for the answer
On Nov 13, 2016, at 1:20 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dean,

Dean

Thanks,
Kent

From: Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 11, 2016 at 3:45 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

Dean

Thanks,
Kent (as shepherd)

As well as:

Thank you,
NETMOD WG Chairs

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Nov 2016 15:01:57 +0100

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 <[email-masked]
> <mailto:[email-masked]>> on behalf of Dean Bogdanovic
> <[email-masked] <mailto:[email-masked]>>
>     I have something that might delay WGLC, but found out an
>     optimization which would help in the future
>
>     Instead of using "leaf" for "destination-ipv4-network" and
>     "source-ipv4-network", "leaf-list" reduces the number of terms/ace
>     needed.
>
>       This allows having matching multiple destinations to 1 source,
>     or multiple sources to 1 destination, if they cannot be easily
>     combined into 1 entry.
>
>>>     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 <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *Date: *Friday, November 11, 2016 at 3:45 PM
>>>     *To: *Kent Watsen <[email-masked] <mailto:[email-masked]>>
>>>     *Cc: *"[email-masked] <mailto:[email-masked]>"
>>>     <[email-masked] <mailto:[email-masked]>>
>>>     *Subject: *Re: [netmod] WG Last Call for
>>>     draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)
>>>      
>>>      
>>>>     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 about the YANG module’s use of the config false nodes
>>>>     ‘acl-oper-data’ and ‘ace-oper-data’.  In particular, are the
>>>>     lifetimes of these nodes always the same as the configured nodes? 
>>>      
>>>     Yes, they are. When the nodes are created, they are don’t have
>>>     to be attached to an another object, like interface or RIB, etc,
>>>     but they get operational state. Once attached, (to continue with
>>>     the example) operational status of counters is changing. When
>>>     detached from the interface, the last know counter is kept,
>>>     until the ace is deleted. Same is for acl-oper-data.
>>>      
>>>>     *From: *netmod <[email-masked]
>>>>     <mailto:[email-masked]>> on behalf of Kent Watsen
>>>>     <[email-masked] <mailto:[email-masked]>>
>>>>     *Date: *Thursday, October 13, 2016 at 5:05 PM
>>>>     *To: *"[email-masked] <mailto:[email-masked]>"
>>>>     <[email-masked] <mailto:[email-masked]>>
>>>>     *Subject: *[netmod] WG Last Call for
>>>>     draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)
>>>>      
>>>>      
>>>>                    _https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09_
>>>>      
> [email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Nov 2016 15:24:02 +0100

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dean and friends,
>
>     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
>
>
>
>
>
>>     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 
>>
>>
>>     Subject: Re: [netmod] WG Last Call for
>>         "source-ipv4-network", "leaf-list" reduces the number of
>>         terms/ace needed.
>>
>>           This allows having matching multiple destinations to 1
>>         source, or multiple sources to 1 destination, if they cannot
>>         be easily combined into 1 entry.
>>
>>>         On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>         Kent,
>>>
>>>         Thank you for the answer
>>>>         On Nov 13, 2016, at 1:20 PM, Kent Watsen
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>         Hi Dean,
>>>>          
>>>>         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?
>>>
>>>         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
>>>>          
>>>>>         On Oct 29, 2016, at 4:01 AM, Kent Watsen
>>>>>         <[email-masked] <mailto:[email-masked]>> 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 about the YANG module’s use of the
>>>>>         config false nodes ‘acl-oper-data’ and ‘ace-oper-data’. 
>>>>>         In particular, are the lifetimes of these nodes always the
>>>>>         same as the configured nodes? 
>>>>          
>>>>         Yes, they are. When the nodes are created, they are don’t
>>>>         have to be attached to an another object, like interface or
>>>>         RIB, etc, but they get operational state. Once attached,
>>>>         (to continue with the example) operational status of
>>>>         counters is changing. When detached from the interface, the
>>>>         last know counter is kept, until the ace is deleted. Same
>>>>         is for acl-oper-data.
>>>>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Nov 2016 15:28:57 +0100

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 <[email-masked]
>     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
>
>
>>     This draft should not move forward, it needs more work to be
>>     useful. Will be working with Dean next week to fix things up.
>>
>>         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
>>
>>
>>
>>
>>
>>>         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 
>>>
>>>
>>>         <mailto:[email-masked]>> on behalf of Dean
>>>         Bogdanovic <[email-masked] <mailto:[email-masked]>>
>>>         Cc: "[email-masked] <mailto:[email-masked]>"
>>>             Instead of using "leaf" for "destination-ipv4-network"
>>>             and "source-ipv4-network", "leaf-list" reduces the
>>>             number of terms/ace needed.
>>>
>>>             source, or multiple sources to 1 destination, if they
>>>             cannot be easily combined into 1 entry.
>>>
>>>>>             > Don’t understand your question. What is the
>>>>>             difference between system and user generated acls?
>>>>>              
>>>>>             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
>>>>>              
>>>>>>             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.
>>>>>>             morning, I’m wondering about the YANG module’s use of
>>>>>>             the config false nodes ‘acl-oper-data’ and
>>>>>>             ‘ace-oper-data’.  In particular, are the lifetimes of
>>>>>>             these nodes always the same as the configured nodes? 
>>>>>              
>>>>>             Yes, they are. When the nodes are created, they are
>>>>>             don’t have to be attached to an another object, like
>>>>>             interface or RIB, etc, but they get operational state.
>>>>>             Once attached, (to continue with the example)
>>>>>             operational status of counters is changing. When
>>>>>             detached from the interface, the last know counter is
>>>>>             kept, until the ace is deleted. Same is for acl-oper-data.
>>>>>              
>>>>>>             <mailto:[email-masked]>> on behalf of Kent
>>>>>>             Watsen <[email-masked] <mailto:[email-masked]>>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Nov 2016 15:54:19 +0000

Yes, this draft is currently past last-call, and not for the first time, and there being two implementations was highly encouraging.   Still, as shepherd and chair, I need to know we have WG consensus on next steps and therefore want to echo Eliot’s request for all and any remaining issues to be brought forward now, or let’s say within the next couple weeks, so we can discuss which changes to accept or not.  To be clear, I’m in effect extending the last-call period for this draft until December 7.

FWIW, the issue I raised regarding if there was a need to support system-generated ACLs resolved as a no-op to the draft.  Dean’s issue regarding changing a leaf to a leaf-list seemed innocuous enough, but Acee’s question remains unanswered.  Additionally, from a pre- Bits-N-Bites meeting I had, I’m aware that other concerns linger, which I hope to see discussed now in this extended last-call period.

Kent  // as shepherd and co-chair

From: Eliot Lear <[email-masked]>
Date: Friday, November 18, 2016 at 9:24 AM
To: David Bannister <[email-masked]>, "Acee Lindem (acee)" <[email-masked]>, Dean Bogdanovic <[email-masked]>, Kent Watsen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

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 <[email-masked]<mailto:[email-masked]>> 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

Kent,

Thank you for the answer

Hi Dean,

Dean

Thanks,
Kent

Dean

Thanks,
Kent (as shepherd)

As well as:

Thank you,
NETMOD WG Chairs

netmod mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Nov 2016 17:53:54 +0000

Hi David,

From: David Bannister <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 23, 2016 at 12:28 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: Eliot Lear <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

Here are my issues with the ACL draft as it stands today from a high level, vs. calling out every missing field.

Although I'm not an author of this YANG model, I'm the author of others and I can say from experience that it would be infinitely more productive for you to list the specific fields and corresponding use cases as opposed to a subjective high-level critique. That way, these can be incorporated or, at least, we can have the discussion as whether or not they belong in the base model.

Thanks,
Acee

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 23 Nov 2016 10:10:15 -0800

Kent,

I want to echo the issue that Adrian Pan brought up earlier on acl-type. The model currently allows for definition of acl-type which it describes as:

"Type of access control list. Indicates the primary intended
         type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
         used in the list instance."

First of all, it is not clear what is meant by "primary intended type of match criteria”. Does it mean that if acl-type is defined as ipv6 and a ipv4 ace entry is added to that acl, that the ipv4 address will be treated as a ipv6 address? Or does it mean that if there is a mix of ipv4 and ipv6 addresses within an acl, that ipv6 address would be selected over ipv4? If the intention is truly to allow mixing of different acl-types, which I am not sure any system supports (Cisco certainly does not), then one can use acl-type of ‘mixed’.

A more intuitive use of acl-type, in my mind, would be to use it to check whether the ace entry matches the acl-type. 

> On Nov 23, 2016, at 7:54 AM, Kent Watsen <[email-masked]> wrote:
> 
>  
> From: Eliot Lear <[email-masked] <mailto:[email-masked]>>
> To: David Bannister <[email-masked] <mailto:[email-masked]>>, "Acee Lindem (acee)" <[email-masked] <mailto:[email-masked]>>, Dean Bogdanovic <[email-masked] <mailto:[email-masked]>>, Kent Watsen <[email-masked] <mailto:[email-masked]>>
>> On Fri, Nov 18, 2016 at 11:02 PM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
>>> Dean and friends,
>>> 
>>>> From: netmod <[email-masked] <mailto:[email-masked]>> on behalf of Dean Bogdanovic <[email-masked] <mailto:[email-masked]>>
>>>>>> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>  
>>>>>> Kent, 
>>>>>>  
>>>>>> Thank you for the answer

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 23 Nov 2016 22:55:39 +0000

If you could just point out the general features you are using in your configs that are not present in the base model. I know you mentioned TCP options matching. With respect to the augmentations, they don't have to be vendor specific. Some advanced ACL functions such as conditional ACLs could be provided in standard model augmentations in future modules.

Thanks,
Acee

From: David Bannister <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 23, 2016 at 1:54 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>, Eliot Lear <[email-masked]<mailto:[email-masked]>>, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

I'm open to the idea given ample time.

On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

Thanks,
Acee

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Nov 2016 15:05:25 -0800

Hi,

I have a general comment, related to Benoit's request to get YANG modules
done.

Augment is your friend.  Use it.
YANG 1.1 even allows conditionally mandatory nodes to be added, so there are
no excuses for not publishing base modules that can be augmented later.

IMO, adding new features in WGLC should not even be considered.

Andy

On Wed, Nov 23, 2016 at 2:55 PM, Acee Lindem (acee) <[email-masked]> wrote:

> If you could just point out the general features you are using in your
> configs that are not present in the base model. I know you mentioned TCP
> options matching. With respect to the augmentations, they don’t have to be
> vendor specific. Some advanced ACL functions such as conditional ACLs could
> be provided in standard model augmentations in future modules.
>
> Thanks,
> Acee
>
> From: David Bannister <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Kent Watsen <[email-masked]>, Eliot Lear <[email-masked]>, Dean
> Bogdanovic <[email-masked]>, "[email-masked]" <[email-masked]>
> On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee) <[email-masked]>
> wrote:
>
>> Hi David,
>>
>> From: David Bannister <[email-masked]>
>> Cc: Eliot Lear <[email-masked]>, Acee Lindem <[email-masked]>, Dean
>> Bogdanovic <[email-masked]>, "[email-masked]" <[email-masked]>
>> Here are my issues with the ACL draft as it stands today from a high
>> level, vs. calling out every missing field.
>>
>>
>> Although I’m not an author of this YANG model, I’m the author of others
>> and I can say from experience that it would be infinitely more productive
>> for you to list the specific fields and corresponding use cases as opposed
>> to a subjective high-level critique. That way, these can be incorporated
>> or, at least, we can have the discussion as whether or not they belong in
>> the base model.
>>
>> Thanks,
>> Acee
>>
>
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 23 Nov 2016 18:17:46 -0500

As draft author, the model was designed to be easily augmented for matches and actions, so that each vendor and user can adapt it to their needs.

Dean

> On Nov 23, 2016, at 6:05 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> I have a general comment, related to Benoit's request to get YANG modules done.
> 
> On Wed, Nov 23, 2016 at 2:55 PM, Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>> wrote:
> If you could just point out the general features you are using in your configs that are not present in the base model. I know you mentioned TCP options matching. With respect to the augmentations, they don’t have to be vendor specific. Some advanced ACL functions such as conditional ACLs could be provided in standard model augmentations in future modules. 
> 
> Thanks,
> Acee 
> 
> From: David Bannister <[email-masked] <mailto:[email-masked]>>
> To: Acee Lindem <[email-masked] <mailto:[email-masked]>>
> Cc: Kent Watsen <[email-masked] <mailto:[email-masked]>>, Eliot Lear <[email-masked] <mailto:[email-masked]>>, Dean Bogdanovic <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi David, 
> 
> From: David Bannister <[email-masked] <mailto:[email-masked]>>
> Cc: Eliot Lear <[email-masked] <mailto:[email-masked]>>, Acee Lindem <[email-masked] <mailto:[email-masked]>>, Dean Bogdanovic <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Although I’m not an author of this YANG model, I’m the author of others and I can say from experience that it would be infinitely more productive for you to list the specific fields and corresponding use cases as opposed to a subjective high-level critique. That way, these can be incorporated or, at least, we can have the discussion as whether or not they belong in the base model. 
> 
> Thanks,
> Acee 
> 
>

---

From: wangzitao <[email-masked]>
Date: Thu, 24 Nov 2016 01:07:33 +0000

+1
I am not co-author of this model, but I had read this draft.
I believe this model can be easily augmented and flexible reused:
The “choice/case” structure can help to insert new “condition” or “action” attributes into the ACL model;
And the “ietf-packet-fields” module which contains several reusable groupings also provide a convenient way to derive specific models.

Best Regards!
-Michael

发件人: netmod [mailto:[email-masked]] 代表 Dean Bogdanovic
发送时间: 2016年11月24日 7:18
收件人: Andy Bierman
抄送: [email-masked]
主题: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

Dean

On Nov 23, 2016, at 6:05 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

On Wed, Nov 23, 2016 at 2:55 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
If you could just point out the general features you are using in your configs that are not present in the base model. I know you mentioned TCP options matching. With respect to the augmentations, they don’t have to be vendor specific. Some advanced ACL functions such as conditional ACLs could be provided in standard model augmentations in future modules.

Thanks,
Acee

Thanks,
Acee