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 > https://www.ietf.org/mailman/listinfo/netmod
signature.asc
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
