IETF Last Call Review of draft-ietf-opsawg-ucl-acl-11
review-ietf-opsawg-ucl-acl-11-secdir-lc-smyslov-2026-01-19-00

Request Review of draft-ietf-opsawg-ucl-acl
Requested revision No specific revision (document currently at 12)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2026-01-26
Requested 2026-01-12
Requested by Mahesh Jethanandani
Authors Qiufang Ma , Qin Wu , Mohamed Boucadair , Daniel King
I-D last updated 2026-02-28 (Latest revision 2026-02-03)
Completed reviews Opsdir Early review of -08 by Dhruv Dhody (diff)
Intdir Early review of -10 by Alexander Pelov (diff)
Secdir IETF Last Call review of -11 by Valery Smyslov (diff)
Yangdoctors IETF Last Call review of -12 by Acee Lindem
Opsdir IETF Last Call review of -11 by Dhruv Dhody (diff)
Comments 
The YANG Doctors and the OPSDIR review have provided an Early Review, so this change should be a quick check. The rest of the review requests are new.
Assignment Reviewer Valery Smyslov
State Completed
Request IETF Last Call review on draft-ietf-opsawg-ucl-acl by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/IZmwkEK3Nb-ej4BcxGvlm0fooss
Reviewed revision 11 (document currently at 12)
Result Has nits
Completed 2026-01-19
review-ietf-opsawg-ucl-acl-11-secdir-lc-smyslov-2026-01-19-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

The document extends the YANG IETF Access Control List Module defined in RFC
8519 with elements policies based on group identity.

The text for YANG module in the Security Considerations section is based on the
templeate defined in draft-ietf-netmod-rfc8407bis and strictly follows this
template. I have no problems with this text (and if there were any problem with
the template text itself, it should be addressed in
draft-ietf-netmod-rfc8407bis).

However, I have one question - it is not clear to me why
/acl:acls/ucl:endpoint-groups/ucl:endpoint-group and
/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/ucl:endpoint-group subtrees are
mentioned there as writable, while
/acl:acls/acl:acl/acl:aces/acl:ace/ucl:effective-schedule subtree is mentioned
as non-writable. Looking at the tree in section 5.1, all these subtrees are
marked as "rw". And it seems to me that schedule must be configurable (thus
writable). But I'm not a YANG expert, sorry if I missed something.

Nits.
Section 9.1 last para: s/s ubtree/subtree

With regard to RADIUS security, I'd suggest to also cite
draft-ietf-radext-deprecating-radius, since RFC 2865 is a bit dated.
draft-ietf-radext-radiusdtls-bis can also be cited in addition to RFC 6614.

I quickly looked over the definition of a new RADIUS attribute and it seems OK
to me, but I'd suggest to consult the RADIUS experts in the RADEXT WG to be
absolutely sure.