Hello

I have been selected to do a routing directorate review of this draft: https://datatracker.ietf.org/doc/draft-ietf-teas-rfc8776-update/14/

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 passed 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 <https://wiki.ietf.org/en/group/rtg/RtgDir>

Document: draft-ietf-teas-rfc8776-update-14.txt
Reviewer: Julien Meuric
Review Date: December 19, 2024
Intended Status: PS

*Summary*
The document has minor issues and nits that should be resolved before publication.

*Minor Issue*
- [Page 17] The te-bandwidth tries to give an example for WDM which I really don't understand. I starts with the term "number", then uses it as "index" ("slot 0") but why would anyone point to a slot when specifying a bandwidth? Since spectral width is already defined in layer 0 types as flexi-m, I believe we should keep WDM te-bandwidth in bytes/s and drop all the WDM-related text (besides, I need an attribute to express the payload bandwidth my WDM tunnels can carry).
- [p 43] On top restoration-scheme-presignaled and restoration-scheme-precomputed, I'don't understand what is refered to by restoration-scheme-preconfigured. (Note that those terms aren't used in the referenced RFC 4872.) Maybe we could consider deprecating it?
- [p64/68] What is the use of the path-computation-error-no-server identity when we already have both path-computation-error-pce-unavailable and path-computation-error-no-dependent-server?

*Nits*
- [p 11 & 103] The description of each module says "The model fully conforms to the NMDA". That seems a bit odd for modules that must be imported to be used (quoting the security section: "The modules by themselves do not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs."). I would at least temper the wording by dropping the word "fully".
- There are multiple instances of double spacing in module descriptions along the YANG specification which may be checked, e.g. in the normal/abnormal performance-metrics-normality enums [p 15].
- [p 85] In Performance Metric groupings' description, only the 1st one appearing in the document expands the PM acronym. Since the descriptions may be read independently, that's inconsistent: either we consider expansion is required and each description should do it at 1st occurrence, or we consider PM is well known is this context and expansion is omitted from all descriptions.
- [p 88] The label-step description says "values _will have to_ be consistent with the sign of label step"; shouldn't it be an RFC-2119 "MUST"?
- [p 94] When defining the path-route-exclude-objects, the augmentation for SRLGs should only say "An SRLG value to be excluded" ("to be included" doesn't apply here).
- [p 107] The short format for "kilobits per second" units should use a lowercase K, i.e. "kbps".
- [p 152] s/have been obsoletes/have been obsoleted/


Regards,

Julien