Hi Med, > 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.
Thank you. I somehow missed the discussion about the new RADIUS attribute in the RADEXT WG (not a good thing for a co-chair, my only excuse is that it was back in 2023 :-)). Thank you for initiating this discussion in the WG and for reminding me that it has been already done. Regards, Valery. > See also inline. > > Cheers, > Med (as author). > > > 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]
