Hi Mahesh, all, Thank you for the review and comments. We just posed draft-ietf-netmod-acl-extensions-04.
Please see more context inline. Cheers, Med De : netmod <netmod-boun...@ietf.org> De la part de Mahesh Jethanandani Envoyé : mardi 5 décembre 2023 23:09 À : Lou Berger <lber...@labn.net> Cc : NETMOD Group <netmod@ietf.org>; NetMod WG Chairs <netmod-cha...@ietf.org> Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03 Hi, I do support this work, as it is much needed, and would like to see it progress. However, I do believe that the document needs to undergo a revision to qualify for LC. Some of the comments are editorial or minor, and can be addressed easily, but others are not. They should all be addressed for the WG to call the document ready. - The Security Considerations section has both the read/write nodes and the read-only nodes as empty (or marked as TBC, which I imagine stands for To Be Completed). This needs to be filled out, or if no nodes are worth any security considerations, it should be stated so, and why. [Med] ACK. We don't repeat what is already in 8519 but focus on key additions in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files - Isn't the YANG model normative portion of the document? Isn't what this document all about? Why is it then in the Appendix? [Med] We are using a script to generate the IANA modules + we are actually following this part from the 8407bis: It is RECOMMENDED to include the URL from where to retrieve the recent version of the module. When a script is used, the Internet- Draft that defines an IANA-maintained module SHOULD include an appendix with the initial full version of the module. Including such an appendix in pre-RFC versions is meant to assess the correctness of the outcome of the supplied script. The authors MUST include a note to the RFC Editor requesting that the appendix be removed before publication as RFC and that RFC IIII is replaced with the RFC number that is assigned to the document. Initial versions of IANA- maintained modules that are published in RFCs may be misused despite the appropriate language to refer to the IANA registry to retrieve the up-to-date module. - Why is the Section titled "Initial Version of the The ICMPv4 Types IANA-Maintained Module", when the model in question is "iana-icmpv6-ty...@2020-09-25.yang<mailto:iana-icmpv6-ty...@2020-09-25.yang>"? [Med] This was a typo. Fixed. - 'defined-sets' and 'aliases' have been defined in a the separate model 'ietf-acl-enh'. Are these sets and aliases defined to be used outside of ACL? If that is the case then having them outside the 'ietf-access-control-list' model makes sense. Otherwise, almost everything in the 'ietf-acl-enh' is an augmentation of the model defined in RFC 8519, as stated in the Introduction of the document [Med] These are defined to be consumed for ACL policies. "The YANG module in this document is solely based on augmentations to the ACL YANG module defined in [RFC8519]." [Med] The intent was to highlight that we are not using a bis approach. Tweaked the paragraph that includes that text for better clarity. If that is the case I see no reason why those containers should not be augmentations into the same model, as in augment "/acl" { container defined-sets { .... } container aliases { ... } } - I just pulled down the latest version (-03) of the draft, and ran into this error. $ pyang ietf-acl-...@2022-10-24.yang<mailto:ietf-acl-...@2022-10-24.yang> iana-icmpv6-ty...@2020-09-25.yang<mailto:iana-icmpv6-ty...@2020-09-25.yang>:1: error: unexpected latest revision "2023-04-28" in iana-icmpv6-ty...@2020-09-25.yang<mailto:iana-icmpv6-ty...@2020-09-25.yang>, should be "2020-09-25". [Med] Fixed. Thanks. - Section 3.4. TCP Flags Handling. The document states that. "Clients that support both 'flags-bitmask' and 'flags' matching fields MUST NOT set these fields in the same request.". Can the model have a must statement to prevent this from being configured inadvertently? [Med] We don't see how to do that with a must statement, hence the normative language in the narrative text. Same for Section 3.5 Fragments Handling [Med] Same answer :-) - There should be clear direction to the RFC Editor on what should be done with revision dates. The same is true for other placeholder text. For example, what is the RFC Editor to do with text "RFC XXXX"? [Med] Done: https://github.com/boucadair/enhanced-acl-netmod/pull/59/files - References in the YANG model should be expanded to include the title of the RFC. [Med] We are echoing references as listed in an IANA registry, so we do not have control over that reference. - Examples are always good. Not only can they be used to validate the model, but users get to understand how it can be used. See other models such as BGP, TCP, BFD on how an example can be added. [Med] We do already have many in the core document. Will consider adding more if needed. - How is this a reference? reference "- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu<http://um.cc.umich.edu/>> [Med] We are echoing a reference as cited in an IANA registry, so we do not have control over that reference. Thanks. [Med] Thanks for the review. Much appreciated. On Dec 4, 2023, at 3:00 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/ The working group last call ends on December 18th (any TZ). 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 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.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
