The important thing to note is that the current model does not prevent ACEs from being configured for each ACL, like most configurations that exist today. As Acee mentions in his e-mail, scaling can be done programmatically also.
Object groups (or containers) are another way to organize rules that constitute an ACE. And object groups can contain other object groups. Instead of having an ACL with a list of rules, one could have an ACL that refers to an object group that contains the rules. And multiple ACL can refer to the same object group. If there is a strong desire for the feature, the authors believe that this can be addressed in the next version of the *RFC*, probably as a bis document (sorry, if I was not clear what I meant by “next version”). Looking at RFC 7950, I see that we can update the model in a backward compatible way, by adding a ‘case’ statement. How about adding a ‘choice’ statement? Would that be backward compatible? If not, we can make an editorial change to add the ‘choice’ statement in the model today, and later in the bis document add the ‘case’ statement for object groups. Cheers. > On Jan 17, 2018, at 4:25 PM, Sonal Agarwal <sagarwa...@gmail.com> wrote: > > Hi Kent, > > The last remaining open issue is about adding containers for addresses > (source, destination) and ports (source, destination). A user has the choice > to use the container or leaf for address (source/dest) and port > (source/dest). With this, the user can use the Yang model to configure scale > ACL's. > > I did some preliminary work on this in August/September last year, but ran > out of time to explore this fully as I had to upload my other changes by > particular dates. > > The non implementation of this does not detract from the usability of the ACL > model. > > Closing the issue to completion will require me to revisit and implement the > yang solution for container support in the model. > > Thanks, > Sonal. > > > On Wed, Jan 17, 2018 at 3:33 PM, Kent Watsen <kwat...@juniper.net > <mailto:kwat...@juniper.net>> wrote: > > H Mahesh, > > >> - There is an open issue in the document (section 8) - are we going > >> to resolve that during WG last call or is this a leftover? > > > > This will be resolved in the next version of the module. It is > > documented under Issues tab in GitHub. Should we remove it from > > the draft? > > Most of Juergen's comments are editorial in nature and can truly be handled > as part of the LC process, but this open issue has me worried, as it may > result in a significant technical change. > > What will it take to close this open issue? Is it just a matter of the > getting the WG to agree that it's not an issue, or do we already know that it > is a real issue and only the solution is pending? > > Thanks, > Kent > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org <mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
