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.