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