Hi, Joe, Alexander, all, Thanks Joe for the reminder. Thanks Alexander for the careful review, all good points. The authors have published a new version which tries to resolve your comments below, we also tracked your comments as issues at https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/issues (see issues #121~#125), and you may see the correlation with the PR changes here. Please also see more reply below inline...
From: Joe Clarke (jclarke) [mailto:[email protected]] Sent: Wednesday, December 17, 2025 1:49 AM To: Alexander Pelov <[email protected]>; [email protected] Cc: [email protected]; [email protected] Subject: Re: draft-ietf-opsawg-ucl-acl-09 early Intdir review I know you had to go through a lot of process hoops to do this review, Alexander. The chairs appreciate it! I know it's a bit later than the other reviews, but authors can you acknowledge you've seen this? Thanks. Joe and Benoît From: Alexander Pelov via Datatracker <[email protected]<mailto:[email protected]>> Date: Saturday, December 13, 2025 at 04:44 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: draft-ietf-opsawg-ucl-acl-09 early Intdir review Document: draft-ietf-opsawg-ucl-acl Title: A YANG Data Model and RADIUS Extension for Policy-based Network Access Control Reviewer: Alexander Pelov Review result: On the Right Track Review of draft-ietf-opsawg-ucl-acl-09 This review was done as an Early Review as requested from INTDIR. The document is generally well-written with a clear problem statement and helpful examples. However, as a reviewer approaching this without having followed the full evolution of the draft, I have identified several inconsistencies regarding terminology, the architectural relationship between group types, and the practical implementation of group identifiers in the forwarding plane. Overall, l think the document needs a rework, and depending on the discussion with the authors that could prove to be minor or major. 1. Terminology It is somewhat difficult to follow the different terminology throughout the document. The "terminology" section itself is quite limited, and there are many similar or related notions used throughout. The core example is the use of "endpoint-group", "group identity", "user group", "application group", and "device group." This inconsistency is particularly visible with the RADIUS Attribute defined in the document, which is called "User-Access-Group-ID". Reading the draft, this attribute appears to be the mechanism for the generic "endpoint group," yet the name seems to suggests its for "Users." I think the document would gain in readability by explicitly defining: "endpoint group", "user group", "device group", and "application group". It is currently unclear what the actual relations are between these types. Sometimes there seems to be a clear hierarchy (e.g., a user uses a device to access an application), but other times, the groups appear "flat" (e.g., matching anything with a given source IP). In the introduction (Page 3), the text states: "This document also defines a mechanism to establish a mapping between (1) the user group identifier (ID) and (2) common IP packet header fields... to execute the policy-based access control." * What about the "device group ID" and "application group ID"? * The example in Figure 1 is very user-oriented, but from my understanding, everything from Step 3 onwards could apply to *any* Endpoint-Group type (e.g., Device-Group), not just Users. Section "4.2. Endpoint Group" has three subsections, each giving a loose description of how the 3 types of groups operate. The relationship between these three notions is unclear. As written, the "User group" concept could effectively cover both Device and Application groups. Why distinguish between three types? It might be cleaner to define a single, generic "Policy Group" and indicate that different entities can belong to it. [Qiufang] Thanks for the valuable comments. A couple of terms have been defined explicitly as suggested, we also add a section to clarify the relation between different endpoint groups and why there is a need to distinguish between these types. You made a good point that some sections of the draft are quite specific to user group and we also need consider device group and application group at the same time. There are some clarification in the draft added that tries to explain the intention. Please review the update and let us know if you have further comments. 2. Precision of Language In Section "4.2.1. User group," the text states: "if the user group membership is determined solely by the source IP address, then a given user's group ID will change when the user moves to a new IP address...". * it is said that "The user group is determined by a set of predetermined policy criteria (e.g. source IP address, geolocation data, time of day, or device certificate)". * "if the user group membership is determined solely by the source IP address, then a given user's group ID will change when the user moves to a new IP address that falls outside of the range of addresses of the previous user group." The wording seems awkward. How does the user "move to a new IP address"? [Qiufang] Sorry for the bad wording. Have fixed this in https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/pull/127/: S/move to a new IP address/ is assigned a new IP address/ 3. Scenarios There are many scenarios and use-cases mentioned. Explicitly defining some of the major scenarios would be beneficial. For example: * NAS with native support for Group-based Policies. * NAS that does not support Group-based Policies. More specifically: Section 4.1, bullet point 4 (The Policy Enforcement Point) ends with "More details are provided in Section 8". However, Section 8 is quite generic and does not seem to provide the detailed scenarios promised in the overview. [Qiufang] Fixed by removing this sentence. 4. Implementation Details and Interoperability On Page 12 it is stated: "How the 'group-id' string is mapped to the tagging or field in the packet header in encapsulation scenario is outside the scope of this document.". I am not sure if there was a discussion at the WG level about this. It seems to me that leaving this entirely out of scope could lead to interoperability issues. String-based matching in the forwarding plane can be expensive. Adding a field such as `NumericGroupID` and `NumericGroupType` would not be too expensive implementation-wise and would significantly aid interoperability with standard encapsulations (e.g., assigning NumericGroupID = 500, NumericGroupType = "VXLAN/GENEVE"). This, however is for the WG to decide. I am curious if this was discussed and agreed upon. [Qiufang] The authors have tracked this at https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/issues/124, and internally think it might be hard to give a stable and unified mapping mechanism here. And such a NumericGroupID definition might be protocol-dependent thus we tend to leave this as augmentation for future work. But it would also be good to receive more comments and feedback from the WG here. 5. RADIUS Considerations Regarding "6. User Access Control Group ID RADIUS Attribute": * "Access-Reject vs. Restricted Accept:" Table 4 lists the attribute quantity for Access-Reject as "0". However, the introduction states that authentication failure might result in the user being "assigned a special group with very limited access permissions". * Usually, an "Access-Reject" terminates the session (no attributes processed). If the intent is to assign a "special group" for limited access, this would technically be a "Restricted Access-Accept". The text should clarify if this scenario results in a Reject (with 0 attributes) or an Accept (with the special Group ID). [Qiufang] Maybe check https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/issues/125 and the updates in https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/pull/129 to see if this is good enough. Thanks a lot! Best Regards, Qiufang //co-author
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
