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 <kwat...@juniper.net> wrote:
>
>
> 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 <l...@cisco.com <mailto:l...@cisco.com>>
> Date: Friday, November 18, 2016 at 9:24 AM
> To: David Bannister <d...@netflix.com <mailto:d...@netflix.com>>, "Acee
> Lindem (acee)" <a...@cisco.com <mailto:a...@cisco.com>>, Dean Bogdanovic
> <ivand...@gmail.com <mailto:ivand...@gmail.com>>, Kent Watsen
> <kwat...@juniper.net <mailto:kwat...@juniper.net>>
> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
> <mailto:netmod@ietf.org>>
> 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 <l...@cisco.com
>> <mailto:l...@cisco.com>> 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 <netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org>> on
>>>> behalf of Dean Bogdanovic <ivand...@gmail.com <mailto:ivand...@gmail.com>>
>>>> Date: Tuesday, November 15, 2016 at 10:06 AM
>>>> To: Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
>>>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
>>>> <mailto: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:
>>>>>
>>>>> <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 <ivand...@gmail.com
>>>>>> <mailto:ivand...@gmail.com>> wrote:
>>>>>>
>>>>>> Kent,
>>>>>>
>>>>>> Thank you for the answer
>>>>>>> On Nov 13, 2016, at 1:20 PM, Kent Watsen <kwat...@juniper.net
>>>>>>> <mailto:kwat...@juniper.net>> 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 <ivand...@gmail.com <mailto:ivand...@gmail.com>>
>>>>>>> Date: Friday, November 11, 2016 at 3:45 PM
>>>>>>> To: Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
>>>>>>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
>>>>>>> <mailto: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 <kwat...@juniper.net
>>>>>>>> <mailto:kwat...@juniper.net>> 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.
>>>>>>>
>>>>>>>> - 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 <netmod-boun...@ietf.org
>>>>>>>> <mailto:netmod-boun...@ietf.org>> on behalf of Kent Watsen
>>>>>>>> <kwat...@juniper.net <mailto:kwat...@juniper.net>>
>>>>>>>> Date: Thursday, October 13, 2016 at 5:05 PM
>>>>>>>> To: "netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
>>>>>>>> <mailto:netmod@ietf.org>>
>>>>>>>> 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
>>>>>>>> <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
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> <https://www.ietf.org/mailman/listinfo/netmod>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> <https://www.ietf.org/mailman/listinfo/netmod>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
