Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-path-computation-yang/

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-ccamp-otn-path-computation-yang
Reviewer: Dhruv Dhody
Review Date: 2026-07-12
Intended Status: Standards

## Summary:
I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

## Comments:

The document is generally well organized and readable. It clearly builds on the existing TE Path Computation YANG model and limits itself to OTN-specific augmentations. The structure follows that of the underlying model closely, which makes the document relatively easy to follow for readers familiar with it.

## Minor:

- Remove otn-link-bandwidth from this text - "with the OTN technology-specific attributes using the otn-link-bandwidth and otn-path-bandwidth groupings", as I did not find any use of that grouping in the YANG model.  

- This might be a copy-paste-error, where the description says 'end' but it should be 'step'  
````
  augment "/te:tunnels-path-compute/te:input/te:path-compute-info/"
        + "te-pc:path-request/te-pc:path-out-segment/"
        + "te-pc:label-restrictions/te-pc:label-restriction/"
        + "te-pc:label-step/te-pc:technology" {
    description
      "Augment TE label range end for the egress segment
       of the requested path.";
    case otn {
      uses l1-types:otn-label-step;
    }
````

- The security consideration says that the YANG module defined in this document augments the "tunnels-path-compute" and the "tunnel-actions" RPCs; but i did not find any "tunnel-actions" in the YANG. 

- RFC 9907 recommends usage examples for YANG modules, did the WG consider adding it?

Thanks! 
Dhruv