Dear all, I completed and submitted the review of -10. The -10 version addresses the issues I raised in the earlier review.
Thanks to the authors for the rapid update of their draft! Cheers, Alexander https://imt-atlantique.webex.com/meet/pelov Alexander PELOV Associate Professor 02 99 12 24 11Technopôle Brest-Iroise CS 83818 29238 Brest Cedex 3 La Chantrerie 4 rue Alfred Kastler BP 20722 44307 Nantes Cedex 3 2, rue de la Châtaigneraie CS 17608 35576 Cesson Sévigné Cedex <https://www.imt-atlantique.fr/> <https://www.facebook.com/IMTAtlantique> <https://www.linkedin.com/school/24772587/> <https://www.instagram.com/imt_atlantique/> <http://www.imt-atlantique.fr/l-ecole/actualites> Une école de l'IMT <https://www.imt.fr/> > On 17 Dec 2025, at 12:23, maqiufang (A) <[email protected]> wrote: > > 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] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[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]
