Hi, Éric, Thanks a lot for your review, the authors have prepared a PR to address your comments : https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/pull/154.
Regarding the issue in Sec.5.2 about "eth", note that the 'eth' term used in this draft is directly inherited from RFC 8519 (which has a set of eth-based identities and features), and the authors tend to keep the naming to maintain consistency with RFC 8519. Interestingly, RFC 8519 seems to include wireless IEEE 802.11 (Wi-Fi) scenarios even when using the "eth" or "Ethernet header". I.e., the definition of eth-acl-type identity in https://datatracker.ietf.org/doc/html/rfc8519#section-4.1: identity eth-acl-type { base acl:acl-base; if-feature "eth"; description "An ACL that matches on fields in the Ethernet header, like 10/100/1000baseT or a Wi-Fi Access Control List. An ACL of type ethernet does not contain matches on fields in the IPv4 header, the IPv6 header, or Layer 4 headers."; } Anyway, 8519 is designed such that additional identities and matching criteria can be added as needed. But it is beyond the scope of this document to expand the scope of L2 matching criteria, which focuses on matching based on the endpoint group identities and date/time attributes. Hopefully this clarifies. Best Regards, Qiufang //co-author -----Original Message----- From: Éric Vyncke via Datatracker [mailto:[email protected]] Sent: Friday, March 27, 2026 11:20 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Éric Vyncke's No Objection on draft-ietf-opsawg-ucl-acl-13: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ucl-acl-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ucl-acl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # É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 ;-) _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
