Hi Med, Thanks for the quick feedback and PR. The changes look good. More inline...
On Tue, Oct 7, 2025 at 2:26 PM <[email protected]> wrote: > Hi Dhuv > > Thanks for the review. A PR to address your comments can be seen at: > https://github.com/IETF-OPSAWG-WG/policy-based-network-acl/pull/114/files. > > Please see inline for more contex. > > Cheers, > Med (as author) > > > -----Message d'origine----- > > De : Dhruv Dhody via Datatracker <[email protected]> > > Envoyé : mardi 7 octobre 2025 07:11 > > À : [email protected] > > Cc : [email protected]; [email protected] > > Objet : draft-ietf-opsawg-ucl-acl-08 early Opsdir review > > > > > > Document: draft-ietf-opsawg-ucl-acl > > Title: A YANG Data Model and RADIUS Extension for Policy-based > > Network Access Control Reviewer: Dhruv Dhody Review result: Has > > Issues > > > > # OPSDIR Early Review of draft-ietf-opsawg-ucl-acl-08 > > > > I have reviewed this document as part of the Operational > > directorate’s ongoing effort to review all IETF documents being > > processed by the IESG. These comments were written with the intent > > of improving the operational aspects of the IETF drafts. > > > > The document is well-written. The motivation is clear. Thank you > > for including the examples. > > > > ## Major > > > > - The relationship between the ietf-ucl-acl and ietf-acl-enh YANG > > modules is unclear. The text suggests that the ACL Extensions work > > ([I-D.ietf-netmod-acl-extensions]) is a foundational dependency, > > while the ietf-ucl-acl module itself does not import or augment > > ietf-acl-enh or is referenced normatively. I suggest this to be > > explicitly clarified. > > [Med] I don't know which part of the text smells like there is strong > dependency between these two. > > Section 3 has already the following: > > The network ACLs can be provisioned on devices using specific > mechanisms, such as [RFC8519] or [I-D.ietf-netmod-acl-extensions]. > > Dhruv: Thanks for this. My initial reading gave a strong dependency on the SDN and thus network-level ACLs based on the architecture and examples. Perhaps some text or example can be added to explicitly state how the model is used on a device without SDN. But only a suggestion and feel free to disregard. <snip> > > > - In A.2, the rule1 and rule2 appear to be inconsistent. rule1 for > > accepting matches on a destination-user-group-id, whereas rule2 > > for rejecting matches on a destination-ipv4-network - please be > > explicit on why the accept, group-id is being used, but for > > reject, ip address is used. > > [Med] That section says: "This example does not intend to be exhaustive." > > The intent was to show the correlation between the id and actual IP > addresses for a rule, but not for all rules. > > BTW, nothing prevents that the same match criteria are used for rules in a > list. > > Dhruv: My suggestion would be to just add some explicit text before the example. Thanks! Dhruv
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
