Reviewer: Sean Turner Review result: Ready 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
