## COMMENTS (non-blocking)

### Section 2

It would have been useful to also provide references to the terms beyond acronyms expansions.

### Section 3.1.1.1

Please expand or add a reference to "RWA" in `No RWA constraints met`

Section 1.2, paragraph 1
>     +=================+======================+========================+
>     | Prefix          | YANG module          | Reference              |
>     +=================+======================+========================+
>     | yang            | ietf-yang-types      | Section 3 of [RFC6991] |
>     +-----------------+----------------------+------------------------+
>     | inet            | ietf-inet-types      | Section 4 of [RFC6991] |
>     +-----------------+----------------------+------------------------+
>     | rt-types        | ietf-routing-types   | [RFC8294]              |
>     +-----------------+----------------------+------------------------+
>     | te-types        | ietf-te-types        | RFCXXXX                |
>     +-----------------+----------------------+------------------------+
>     | te-packet-types | ietf-te-packet-types | RFCXXXX                |
>     +-----------------+----------------------+------------------------+

Please update all references to RFC6991 to point to RFC 9911.

Section 4, paragraph 14
>         All revisions of IETF and IANA published modules can be found
>         at the YANG Parameters registry group
>         (https://www.iana.org/assignments/yang-parameters).

Is this draft publishing an IANA module? If not, please remove reference to IANA modules.

Section 4, paragraph 34
>      identity lsp-provisioning-error-reason {
>        description
>          "Base identity for LSP provisioning errors.";
>      }

I do not see this base identity being used in this module or in this document. If this is intended to be used somewhere else or at a later time, it would be better to define it there or at that time.

Section 4, paragraph 358
>        leaf one-way-delay {
>          type uint32 {
>            range "0..16777215";
>          }
>          units "microseconds";
>          description
>            "One-way delay or latency.";
>        }

Is there a reference that can be cited for this? Or even an explanation for how it can be measured. Per MEF 10.3, "One-way delay is difficult to measure and therefore one-way delay may be approximated from two-way measurements."

Section 4, paragraph 357
>        leaf one-way-delay-normality {
>          type te-types:performance-metrics-normality;
>          description
>            "One-way delay normality.";
>        }

This description and several like these are essentially a repeat of the name of the node without an explanation for what it is. Either an explanation or a reference is the minimum one should expect from these modules.

Section 4, paragraph 358
>        leaf two-way-delay {
>          type uint32 {
>            range "0..16777215";
>          }
>          units "microseconds";
>          description
>            "Two-way delay or latency.";
>        }

Same question here for reference.

Section 5, paragraph 0
>    The "ietf-te-packet-types" module imports from the "ietf-te-types"
>    module defined in Section 4 of this document.

How about RFC 6991 or more precisely RFC 9911?

Section 5, paragraph 1
>      // RFC Editor: Please replace XXXX above with the RFC number
>      // assigned to this document.
>      // Please remove this note.

Can all these RFC Editor directives be consolidated in one place instead of scattering them across the document?

Section 5, paragraph 54
>      grouping bandwidth-profile-parameters {
>        description
>          "Common parameters to define bandwidth profiles in packet
>           networks.";
>        leaf cir {
>          type uint64;
>          units "bits per second";
>          description
>            "Committed Information Rate (CIR).";
>        }
>        leaf cbs {
>          type uint64;
>          units "bytes";
>          description
>            "Committed Burst Size (CBS).";
>        }
>        leaf eir {
>          type uint64;
>          units "bits per second";
>          description
>            "Excess Information Rate (EIR).";
>        }
>        leaf ebs {
>          type uint64;
>          units "bytes";
>          description
>            "Excess Burst Size (EBS).";
>        }
>        leaf pir {
>          type uint64;
>          units "bits per second";
>          description
>            "Peak Information Rate (PIR).";
>        }
>        leaf pbs {
>          type uint64;
>          units "bytes";
>          description
>            "Peak Burst Size (PBS).";
>        }
>      }

Please cite the reference of MEF 10.3 for these parameters as suggested by Sergio Belotti. BTW, thanks, Sergio, for your OPSDIR review.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "he"; alternatives might be "they", "them", "their"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Reference [RFC6991] to RFC6991, which was obsoleted by RFC9911 (this may be on
purpose).

"I", paragraph 53
>  with the alternate route being pre-computed and stored for use when the fai
>                                 ^^^^^^^^^^^^
Do not mix variants of the same word ("pre-compute" and "precompute") within a
single text.

"I", paragraph 196
> es a type representing the access type of a TE link."; reference "RFC 3630: T
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

"I", paragraph 210
> ition, and the user traffic is being transported (or selected) on the recove
>                             ^^^^^^^^^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

"I", paragraph 333
>  address or dotted quad address or as an URI. The type data node disambiguate
>                                       ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

"I", paragraph 397
> c-editor.org/rfc/rfc9522>. Appendix A. The Complete Schema Trees This appendi
>                                       ^^
It seems like there are too many consecutive spaces here.

Section 8, paragraph 10
> ready defined in [RFC8776], have been updated in the 'explicit-route-hop': -
>                                  ^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

Section 8, paragraph 11
> n replaced by must statements that requires at least the presence of: o node
>                                    ^^^^^^^^
Possible subject-verb agreement error detected.

Section 8, paragraph 12
> n replaced by must statements that requires at least the presence of: o node
>                                    ^^^^^^^^
Possible subject-verb agreement error detected.

Section 8, paragraph 14
> constraints; The following new leaf have been added to the 'tunnel-constraint
>                                     ^^^^
The verb form "have" does not seem to match the subject "leaf".

Section 8, paragraph 15
> jects-always; The container has been renamed as 'explicit-route-objects'. Thi
>                                 ^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.