On 8 Jan 2018, at 15:31, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email protected]<mailto:[email protected]>> wrote:
Hi Einar, Jon, Mahesh, My gut instinct is that making this a grouping might not be a good idea: 1) If somebody updates the core ACL model, will then need to check that anyone using it should be similarly updated (unless they use import-by-revision). Groupings and typedefs are subject to the same backwards-compatibility constraints as any other data. Thus updates to the model should always be trouble-free if the updates conform to RFC 6020/7950 backwards-compatibility rules for model updates. 2) Does it make sense to define ACLs in separate places. Would like be more simple if ACLs were defined in a central place and then just referenced by other protocols as required. Jon clearly has a case he is thinking about, and making an access list container reusable doesn’t seem like an intrinsically bad idea to me. What may be an irritating thing is if there are >1 use case for this and each use case is in effect required to define it’s own idea of a list of access list definitions. 3) I think that groupings are probably overused and I think that they can detract from the readability of the model. (I regard the OpenConfig YANG models as an extreme example of this, where it is necessary to compile the modules together to figure out where everything fits together). I’m not going to disagree with your comments on the overuse of groupings. We could also refer to Cisco IOS-XR native models, where we have some models with 8 levels (perhaps more?) of nested groupings ;-) Having said that, I don't think that this issue is important enough to have a long discussion about ... Likewise. I have no objection to this change, but no strong vested interest either. What I’m most interested in is getting to an agreed model at this point, and this change wouldn’t impact that as it doesn’t change the actual model. Jon — could you perhaps articulate your use case(s)? And perhaps update https://github.com/netmod-wg/acl-model/issues with them? Cheers, Einar Thanks, Rob On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote: Since this is a 7-line change, I see no harm in it if no-one objects? Mahesh has the token for rolling in updates discussed just prior to the end of 2017. Here’s a possible diff: $ git diff -b diff --git a/src/yang/ietf-access-control-list.yang b/src/yang/ietf-access-control-list.yang index 4d698c9..b1a173f 100644 --- a/src/yang/ietf-access-control-list.yang +++ b/src/yang/ietf-access-control-list.yang @@ -402,6 +402,10 @@ module ietf-access-control-list { /* * Configuration data nodes */ + grouping access-lists-top { + description + "Grouping to allow reuse of access lists container elsewhere."; + container access-lists { description "This is a top level container for Access Control Lists. @@ -576,6 +580,9 @@ module ietf-access-control-list { } } } + } + uses access-lists-top; + augment "/if:interfaces/if:interface" { description "Augment interfaces to allow ACLs to be associated in either the Cheers, Einar On 8 Jan 2018, at 10:53, Jon Shallow <[email protected]<mailto:[email protected]>> wrote: Hi There, I appreciate that this is late to the table, but is it possible to set up “access-lists” as a “grouping” in the YANG data model so that “access-lists” can be included by “uses” in a higher level YANG data model? I have raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues Regards Jon _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
