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.


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”? 


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.


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.


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).