Hi Med, Thanks for addressing my comments. I am good with the draft.
Cheers. > On May 14, 2024, at 11:32 AM, mohamed.boucad...@orange.com wrote: > > Hi Mahesh, all, > > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/07/ > <https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/07/> has > now the sets defined as reusable groupings + augment the ACL models. The > structure is basically a revert back to what we used to have in -00. > > Cheers, > Med > > De : netmod <netmod-boun...@ietf.org> De la part de Mahesh Jethanandani > Envoyé : mardi 30 avril 2024 02:58 > À : Lou Berger <lber...@labn.net> > Cc : NETMOD Working Group <netmod@ietf.org>; NETMOD WG Chairs > <netmod-cha...@ietf.org> > Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-06 > > > > 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 > <mailto:lber...@labn.net>> wrote: > > All, > > This starts working group last call on > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions/ > <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 <mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> > > > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > > > > > > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
