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> Date: Friday, November 18, 2016 at 9:24 AM To: David Bannister <d...@netflix.com>, "Acee Lindem (acee)" <a...@cisco.com>, Dean Bogdanovic <ivand...@gmail.com>, Kent Watsen <kwat...@juniper.net> Cc: "netmod@ietf.org" <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 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 _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
