# 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