Kent, Thank you for the answer > On Nov 13, 2016, at 1:20 PM, Kent Watsen <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> > Date: Friday, November 11, 2016 at 3:45 PM > To: 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) > > >> 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 >> <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 >> <https://www.ietf.org/mailman/listinfo/netmod> > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
