Hi Lou, I have reviewed the document and believe it is ready for publication barring one comment and one clarification from Joe. I refer to this thread:
https://mailarchive.ietf.org/arch/msg/netmod/QrixYe6E4R9TFZ0O0S7eBaj4RyY/ <https://mailarchive.ietf.org/arch/msg/netmod/QrixYe6E4R9TFZ0O0S7eBaj4RyY/> In particular, this comment from that thread. What I wanted to add for clarification, is that I agree with Joe on defining a grouping for defined-sets that can then be used by other models. However, when it comes to the ACL extension model itself, I believe that defined-sets should be defined as an augmentation of the ACL model, and should not be defined as a standalone container sitting at the root of the config tree. See sample YANG code below. > I actually agree with your above statement in the Introduction that you had, > about the module being solely an enhancement of the ACL YANG model, and was > surprised to see it taken out. The point I was making was that just like what > you have done with augmenting > "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches” to add ‘choice payload’, > ‘choice alias’ etc, you could have augmented “/acl:acls” to add > ‘defined-sets’ and ‘aliases’. > > Right now, as is, the ietf-acl-enh module sits on the root of the config > tree, with no relation to the ACL model, other than references to it from > within the ACL model. If the definitions in ietf-acl-enh are to be consumed > by the ACL model only, why not augment the ACL model (as shown below) to add > them in the ACL tree? > > > > [Med] This is fair. Now that I managed to refresh the context in my mind I > confirm that we have done that in a previous version of the spec, but the > feedback we received from the WG was to move those upper in the hierarchy > (because there might be other cases). See for example > https://datatracker.ietf.org/doc/minutes-115-netmod-202211080930/ > <https://mailarchive.ietf.org/arch/msg/netmod/QrixYe6E4R9TFZ0O0S7eBaj4RyY/%3Ca%20href=>" > > rel="nofollow">https://datatracker.ietf.org/doc/minutes-115-netmod-202211080930/ > <https://datatracker.ietf.org/doc/minutes-115-netmod-202211080930/>: > > > > == > > Joe Clarke: It would be nice in a standalone container (i.e. groupings that > could be imported). I see some other use cases for these defined groupings > besides just ACLs. > > == > I know that routing policy uses defined-sets, but I believe they have already defined their own. Which other models do you foresee using these groupings (which I am now correcting to as ask, “… using this standalone container”?). > > > If that is the case I see no reason why those containers should not be > augmentations into the same model, as in > > > augment “/acl:acls” { > > container defined-sets { > > …. > > } > > > container aliases { > > … > > } > > } > > > On Apr 29, 2024, at 2:41 PM, Lou Berger <lber...@labn.net> wrote: > > All, > > This starts working group last call on > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/ > > The working group last call ends on May 13th. > Please send your comments to the working group mailing list. > > Positive comments, e.g., "I've reviewed this document > and believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > Lou (Co-Chair & doc Shepherd) > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > 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
