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 https://www.ietf.org/mailman/listinfo/netmod