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.

- Isn’t the YANG model normative portion of the document? Isn’t what this document all about? Why is it then in the Appendix?

- Why is the Section titled "Initial Version of the The ICMPv4 Types IANA-Maintained Module”, when the model in question is "iana-icmpv6-types@2020-09-25.yang”?

- ‘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

"The YANG module in this document is solely based on augmentations to the ACL YANG module defined in [RFC8519].”

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-enh@2022-10-24.yang 
iana-icmpv6-types@2020-09-25.yang:1: error: unexpected latest revision "2023-04-28" in iana-icmpv6-types@2020-09-25.yang, should be "2020-09-25”.

- 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?

Same for Section 3.5 Fragments Handling

- 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"?

- References in the YANG model should be expanded to include the title of the RFC.

- 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.

- How is this a reference?
        reference
          "- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>

Thanks.

> On Dec 4, 2023, at 3:00 PM, Lou Berger <lberger@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
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com