Early Review of draft-ietf-opsawg-ucl-acl-08
review-ietf-opsawg-ucl-acl-08-opsdir-early-dhody-2025-10-06-00

# 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.

## Minor

- "A PEP exposes a NETCONF interface [RFC6241] to an SDN controller" - why
NETCONF only and not say a YANG-based interface to allow any protocol,
including RESTCONF?

- It might be better to make it explicit that Figure 1 is an 'example' or a
'typical' architecture. The text in the section clarifies that there are
various options possible.

- Section 5.1, what is this text referring to - "Note that the data model
augments the definition of "recurrence" grouping with a "duration" data node to
specify the duration of time for each occurrence the policy activation is
triggered"? - I could not locate this in the YANG model.

- 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.

- Section 6.1, the YANG module description should clearly state what the term
UCL stands for; use of prefix uacl adds to the confusion.

## Nits

- Replace 'he/she' with 'they'

Thanks!
Dhruv