Thanks to the authors for bringing forth this work. The document is well written, and the review from Dhruv and Alexander (thanks to both of them) has further improved the document.
The expert review made reading this document easier, and I had only a few comments that I think will further improve the draft. ------------------------------------------------------------------------------- COMMENT ------------------------------------------------------------------------------- Section 8, paragraph 0 > The UCL model can be implemented in different ways. This operational considerations section discusses what is more deployment considerations rather than operational considerations, and as such the title should reflect that. For operational considerations, it would be nice to document the "mapping" problem. It is clear that the draft relies on the network's ability to map a packet's IP to a Group ID. The document discusses using RADIUS to push these mappings, but in a multi-vendor environment, ensuring the Consistency of Group IDs across the entire fabric is an operational challenge not fully solved by the protocol alone. Then there is the performance impact. Applying group-based lookups can sometimes require additional hardware resources (TCAM) on switches compared to standard L3/L4 lookups. The draft assumes the PEP can handle these tags natively. This impact should be called out. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 5.2, paragraph 2 > prefix uacl; I will note that Dhruv pointed out the use of the prefix "uacl", which while being a prefix can be confusing. Why not just use "ucl"? Section 5.2, paragraph 3 > Copyright (c) 2025 IETF Trust and the persons identified > as authors of the code. All rights reserved. Update the Copyright year to 2026. These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/radius-types Section 2, paragraph 12 > , enterprise networks) requires to recognize the endpoints' identities no ma > ^^^^^^^^^^^^ Did you mean "recognizing"? Or maybe you should add a pronoun? In active voice, "require" + "to" takes an object, usually a pronoun. Section 3, paragraph 1 > k administrator may also require to enforce traffic shaping (Section 2.3.3.3 > ^^^^^^^^^^ Did you mean "enforcing"? Or maybe you should add a pronoun? In active voice, "require" + "to" takes an object, usually a pronoun. Section 4.1, paragraph 3 > ured with user credentials (e.g., user name and password), possible group ide > ^^^^^^^^^ It's more common nowadays to write this noun as one word. Section 4.1, paragraph 11 > d to be authenticated (e.g., using user name and password) at the NAS. Step 3 > ^^^^^^^^^ It's more common nowadays to write this noun as one word. Section 4.1, paragraph 11 > to store user credentials, e.g., user name, password, group information, and > ^^^^^^^^^ It's more common nowadays to write this noun as one word. "I", paragraph 29 > o push these mappings, but in a multi-vendor environment, ensuring the Consi > ^^^^^^^^^^^^ This word is normally spelled as one. "I", paragraph 30 > such cases, PEPs do not require to implement specific logic (including hardwa > ^^^^^^^^^^^^ Did you mean "implementing"? Or maybe you should add a pronoun? In active voice, "require" + "to" takes an object, usually a pronoun. Cheers Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
