Hi Valery, Thank you for the review.
You can see https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/issues/141 for more details on how your comments are addressed, including the exact implemented changes. See also inline. Cheers, Med (as author). > -----Message d'origine----- > De : Valery Smyslov via Datatracker <[email protected]> > Envoyé : lundi 19 janvier 2026 14:36 > À : [email protected] > Cc : [email protected]; [email protected]; > [email protected] > Objet : draft-ietf-opsawg-ucl-acl-11 ietf last call Secdir review > > > Document: draft-ietf-opsawg-ucl-acl > Title: A YANG Data Model and RADIUS Extension for Policy-based > Network Access Control Reviewer: Valery Smyslov Review result: Has > Nits > > 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. [Med] Good catch. Added a discussion about effective-schedule under the writeable data nodes as well. > > Nits. > Section 9.1 last para: s/s ubtree/subtree [Med] We don't have this in the md file, but this is present in the generated txt. Tried some tweaks, but will leave it to the RFC editor if this persists. > > 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. [Med] Good suggestions. Done. > > 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. [Med] Already done as you can see at: https://mailarchive.ietf.org/arch/msg/radext/bU35XCHTDtD52LMnnYook0MAEgU/ ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
