Skip to main content

Early Review of draft-ietf-teas-rfc8776-update-14
review-ietf-teas-rfc8776-update-14-rtgdir-early-meuric-2024-12-19-00

Request Review of draft-ietf-teas-rfc8776-update-14
Requested revision 14 (document currently at 23)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2024-12-13
Requested 2024-11-12
Requested by Oscar Gonzalez de Dios
Authors Italo Busi , Aihua Guo , Xufeng Liu , Tarek Saad , Igor Bryskin
I-D last updated 2026-05-21 (Latest revision 2026-05-20)
Completed reviews Yangdoctors Early review of -14 by Joe Clarke (diff)
Rtgdir Early review of -14 by Julien Meuric (diff)
Yangdoctors IETF Last Call review of -19 by Joe Clarke (diff)
Opsdir IETF Last Call review of -19 by Sergio Belotti (diff)
Secdir IETF Last Call review of -19 by Tero Kivinen (diff)
Genart IETF Last Call review of -20 by Joel M. Halpern (diff)
Tsvart IETF Last Call review of -19 by David L. Black (diff)
Comments
Revision 13 went through the second working group last call.
Assignment Reviewer Julien Meuric
State Completed
Request Early review on draft-ietf-teas-rfc8776-update by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/gP0_kdpTdUY5DdBqx20sb_DrbUY
Reviewed revision 14 (document currently at 23)
Result Has issues
Completed 2024-12-19
review-ietf-teas-rfc8776-update-14-rtgdir-early-meuric-2024-12-19-00
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