Hi Mahesh, all, 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 <[email protected]> De la part de Mahesh Jethanandani Envoyé : mardi 30 avril 2024 02:58 À : Lou Berger <[email protected]> Cc : NETMOD Working Group <[email protected]>; NETMOD WG Chairs <[email protected]> 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/ 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/: == 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ 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.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
