Thanks for your work in this document. I have some non-blocking COMMENTS that I share in the hope of helping to improve the document.


Section 1. Introduction

+1 to Deb's comment on clarifying "flushing out the MAC address".

I think it would be helpful to separate the last sentence into two, as follows:
"The document does not specify how to map the policy group identifiers to dedicated fields. Group-Based Policy (GBP), discussed in Section 6.2.3 of [RFC9638], provides an example of how that may be achieved."


Section 3. Usage

I found the following sentence hard to parse and suggest a possible alternative. 

OLD
An alternate approach is to configure endpoint groups to classify users, enterprise devices and applications and associate ACLs with endpoint groups so that endpoints in each group can share a group of ACL rules.

NEW
An alternate approach is to configure endpoint groups to classify users, enterprise devices, and applications, and to associate ACLs with endpoint groups so that endpoints in each group can share a group of ACL rules.

thank you to the authors for the quick turn around and the -14 resolving all my issues.


Thanks to all the reviewers for the insightful comments and the authors that already responded to them; very helpful.  The document shows the results of its in depth review.

* Can there be a definition of “enterprise” or “enterprise device” added to Section 2.  Something like:
  > Enterprise device: for the purposes of this document, an enterprise device is a computing device which falls under the access control domain of centrally managed authority.  A personal device (bring your own device (BYOD)) may temporarily be considered an enterprise device when it is used to access resources controlled by the centrally managed authority.

  I can’t bring together the concepts in the document of BYOD (for example) and then the language in section 4.2.2; or I’m missing a distinction by what is meant by “enterprise device” in 4.2.2



NITS:

* "R&D Regular" (in the text) doesn't exist in the table
  > 441	   groups may share several common criteria.  That is, user group
  > 442	   criteria are not mutually exclusive.  For example, the policy
  > 443	   criteria of user groups R&D Regular and R&D BYOD may share the same
  > 444	   set of users that belong to the R&D organization, and differ only in
  > 445	   the type of clients (firm-issued clients vs. users' personal
  > 446	   clients).  Likewise, the same user may be assigned to different user
  > 447	   groups depending on the time of day or the type of day (e.g.,
  > 448	   weekdays versus weekends), etc.
  > 
  > 450	       +============+==========+===================================+
  > 451	       | Group Name | Group ID | Group Description                 |
  > 452	       +============+==========+===================================+
  > 453	       | R&D        | foo-10   | R&D employees                     |
  > 454	       +------------+----------+-----------------------------------+
  > 455	       | R&D BYOD   | foo-11   | Personal devices of R&D employees |
  > 456	       +------------+----------+-----------------------------------+
  > 457	       | Sales      | foo-20   | Sales employees                   |
  > 458	       +------------+----------+-----------------------------------+
  > 459	       | VIP        | foo-30   | VIP employees                     |
  > 460	       +------------+----------+-----------------------------------+
  > 
  > 462	                        Table 1: User Group Examples
  >

Thanks to Valery Smyslov for their secdir review.  I will note that consulting w/ radext in 2023 is hardly recent, authors should not chastise reviewers that miss that.

Section 1, second to last para:  Is the phrase 'flushing out' a well known technical term?  Perhaps it should be replaced with 'clearing'?

nit:  Section 2 bullets in the html version are not quite right.  I'm sure the editor will fix this... (the text version seems to be better).

# Éric Vyncke INT AD comments for draft-ietf-opsawg-ucl-acl-13
CC @evyncke

Thank you for the work put into this document. PLEASE see and respond on my issue on section 5.2 about 'eth'.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Chongfeng Xie  for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

### Section 1

IPv6 temporary addresses also changes periodically, should it be mentionned ? (linked to `Endpoints do not have stable IP addresses`).

Moreover, Happy Eyeball can swing between IPv4 and IPv6 addresses, does it also have an impact?

Should there be mention of NAPT (mainly IPv4) or proxies where several end-points share the same IP address(es)?

Thanks for citing RFC 9797 ;-)

### Section 4.1

Please expand NAS at first use as it is not part of the RFC Editor well-known abbreviations list (https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list)

Endpoint is often identified in this section by `packet header (e.g., IP/MAC)` but never by the 802.1X session or by the switch port, is it intentional ? Should there be text explaining why the I-D does not apply on a per-interface, per-session ?

### Section 5.2

I hesitated to ballot DISCUSS on this issue, why using 'Ethernet' (or rather 'eth') in several leaves names as most of attachments in 2026 are over Wi-Fi ? *STRONGLY* suggest to s/eth/ieee802/ or something similar.

### Section A.3

Thank you for adding IPv4 example (for history). While I appreciate that not everyone is a network historian, `192.168.2.1/24` was not a network but was a node, i.e., 192.168.2.1/24 => 192.168.2.0/24

Same thing for 2001:db8::1/64 > 2001:db8::/64

### Acknowledgements

Who is the "we" in `We would like` ? I guess that in this case this is the authors, but it is quite strange for an author to thank himself ;-)

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

I did not see any transport-realated topics.

# IESG review of draft-ietf-opsawg-ucl-acl-13

CC @MikeBishop

## Nits

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.

### Typos

#### Section 4.2.1, paragraph 3
```
-    defined.  Such considerations are deployment specific and are out of
-                                                ^
+    defined.  Such considerations are deployment-specific and are out of
+                                                ^
```

#### Section 4.3, paragraph 1
```
-    Policies enforcement can be targeted to different endpoint groups in
-         ^^^
+    Policy enforcement can be targeted to different endpoint groups in
+         ^
```

### Outdated references

Document references `draft-ietf-netmod-RFC8407bis`, but that has been published
as `RFC9907{quote}.

### Grammar/style

#### "Abstract", paragraph 2
```
ions and Management Area Working Group Working Group mailing list (opsawg@iet
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This phrase is duplicated. You should probably use "Working Group" only once.

#### Section 5.1, paragraph 4
```
not need to mirror exactly the "group id" used to populate the policy. How th
                                      ^^
```
This abbreviation for "identification" is spelled all-uppercase.

#### Section 5.2, paragraph 32
```
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.

#### Section 5.2, paragraph 33
```
 put in place to map a Group ID to packets fields, typically managed by a con
                                   ^^^^^^^
```
Nouns are not usually modified by plural nouns. Is it possible that you meant
to use the singular or possessive form here?

#### Section 11, paragraph 4
```
 starting at 8:30:00 of January 20, 2026 with an offset of -08:00 from UTC (
                                    ^^^^
```
Some style guides suggest that commas should set off the year in a
month-day-year date.

I do not see any editorial or INT-related issues (not already covered by Éric that is)