Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from [10.244.8.156] (unknown [104.131.183.230])
	by ietfa.amsl.com (Postfix) with ESMTP id 2A060C151061;
	Thu, 19 Dec 2024 09:50:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Julien Meuric via Datatracker <noreply@ietf.org>
To: <rtg-dir@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.31.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: 
 <173463062972.43439.15195963635692665484@dt-datatracker-65f549669d-lhv7k>
Date: Thu, 19 Dec 2024 09:50:29 -0800
Message-ID-Hash: PH4L4TJDZ5BZIGENBSJ4QDAL5IQNEYUK
X-Message-ID-Hash: PH4L4TJDZ5BZIGENBSJ4QDAL5IQNEYUK
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-teas-rfc8776-update.all@ietf.org, teas@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Julien Meuric <julien.meuric@orange.com>
Subject: =?utf-8?q?=5BRTG-DIR=5DRtgdir_early_review_of_draft-ietf-teas-rfc8776-update?=
	=?utf-8?q?-14?=
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rtg-dir/gP0_kdpTdUY5DdBqx20sb_DrbUY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Reviewer: Julien Meuric
Review result: Has Issues

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



