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