Hurry?! Please look at the history of this draft.
On 11/18/16 3:27 PM, David Bannister wrote: > If you are in a hurry use your vendor model. > > On Fri, Nov 18, 2016 at 11:24 PM Eliot Lear <l...@cisco.com > <mailto:l...@cisco.com>> wrote: > > 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
