Last Call Review of draft-ietf-netmod-acl-extensions-14
review-ietf-netmod-acl-extensions-14-secdir-lc-turner-2025-02-22-00

Hi! I (finally) reviewed this I-D. First a couple of caveats before I get to
the review: - I read the entire I-D; I mean it is an 80 page document with 60
pages of YANG ;) - I did not validate the YANG modules; assumed the authors +
DRs did. - I did not confirm that the module conforms to the NMDA.

I picked ready to go because I think my comments and question below are going
to be easy to resolved.

With that out of the way, on to the review!

Section 1.1: Do you want to ask the RFC editor to update the 4 Copyright years
in the Appendices to match the Copyright year that will be in the Copyright
Notice? Right now they are 2024, 2020, 2023, and 2023; just asking because I
also note that the filename includes the same years.

Section 3.2 defines protocol sets as follows:

Protocol sets:  A protocol set contains a list of protocol values.
 Each protocol can be identified either by a number (e.g., 17) or a
 name (e.g., UDP).

The "or" there makes me wonder whether there is ever going to be a chance when
somebody use a number and somebody else uses a name. How does the matching
work? Is that where the alias comes to play?

The Security Considerations mirror other YANG module security considerations,
i.e., the first three paragraph follow the same format. The bullets in the 3rd
paragraph as where it gets interesting.  Any chance we could add what might
happen if an attacker got a view of defined-sets:

'defined-sets':  Unauthorized read access of these lists will allow
  an attacker to identify the actual resources that are bound to
  ACLs.

Maybe something along the lines of "disclosure of this information could
potentially aid an attacker during a network exploit"?

Mia culpa: I don’t know enough to validate the final paragraph of the Security
Considerations.