Dear Qiufang, Thanks for making all these changes so rapidly!
I’ll review in more details the closed issues (121, 122, 123 and 125) and get back to you by the end of the week. Do you prefer by email or via GitHub? I have a follow-up question on #124. 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]
