IETF Last Call Review of draft-ietf-ccamp-rfc9093-bis-15
review-ietf-ccamp-rfc9093-bis-14-genart-lc-fossati-2025-06-11-01

Hi Italo,

Thanks for addressing my comments.
I have reviewed -15 and it all looks good.
I will update my review accordingly.

cheers, t

PS: you introduced a small typo ("the the")

On Tue, 17 Jun 2025 at 16:31, Italo Busi <Italo.Busi@huawei.com> wrote:
>
> Hi Thomas,
>
> Thanks for your review and comments
>
> We have included most of your proposed changes in the -15 version we have
just uploaded > > Please find below our replies for the changes we have not
included exactly as you have proposed > > Sergio and Italo (on behalf of
co-authors and contributors) > > > -----Original Message----- > > From: Thomas
Fossati via Datatracker <noreply@ietf.org> > > Sent: mercoledì 11 giugno 2025
15:48 > > To: gen-art@ietf.org > > Cc: ccamp@ietf.org;
draft-ietf-ccamp-rfc9093-bis.all@ietf.org; last- > > call@ietf.org > > Subject:
[CCAMP]draft-ietf-ccamp-rfc9093-bis-14 ietf last call Genart review > > > >
Document: draft-ietf-ccamp-rfc9093-bis > > Title: Common YANG Data Types for
Layer 0 Networks > > Reviewer: Thomas Fossati > > Review result: Ready with
Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General
Area Review > > Team (Gen-ART) reviews all IETF documents being processed by
the IESG for > > the IETF Chair.  Please treat these comments just like any
other last call > > comments. > > > > For more information, please see the FAQ
at > > > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > > > Document:
draft-ietf-ccamp-rfc9093-bis-14 > > Reviewer: Thomas Fossati > > Review Date:
2025-06-11 > > IETF LC End Date: 2025-06-23 > > IESG Telechat date: Not
scheduled for a telechat > > > > Summary: > > > > This document obsoletes RFC
9093: this is all correctly signalled in the > > header, abstract and intro. 
The changes from 9093 are clearly listed in > > Appendix B, which is great. > >
> > The IANA section is good. > > > > In general, the document is nicely
written.  I only have a bunch of tiny > > editorial fixes and a couple of
suggestions to make to the editors. > > > > I was unable to assess Section 3,
as it lies completely outside my area of > > expertise. > > > > Major issues:
none > > > > Minor issues: > > > > Section 2: Please check the definition of
“wavelength-assignment”, which > > doesn’t look correct. > > > > I am very
unsure about this one but here you go :-) Is the definition of > >
common-organizational-explicit-mode: “A YANG grouping to define the > > common
capabilities attributes limit range in case of operational mode and > >
explicit mode.” correct?  I cannot parse the “common capabilities attributes >
> limit range” bit; is that the intended phrasing? > > > > [Authors] This
grouping has been replaced by the common-all-modes grouping in an earlier
update. We have replaced the grouping name and definition accordingly. > > >
Nits/editorial comments: > > > > * Section 1: s/model(s)/models/ > > * Section
2: s/ietf- layer0-types/ietf-layer0-types/ > > * Section 2: s/label-
start/label-start/ > > * Section 2: s/the range of available nominal central
frequencies are/the > > range of available nominal central frequencies is/ > >
* Section 2: s/with the > > proper XPath which depends from where this
grouping/with the proper > > XPath, which depends on where this grouping/ > > >
* Section 2: s/optical > > impairments limits/optical impairment limits/ > >
[Authors] There are multiple optical impairments: we have rephrased the
sentence. > > > * Section 2: s/Signal to Noise > > Ratio/Signal-to-noise ratio/
* Section 2.1: s/frequency slots associated to the > > WDM LSP/frequency slots
associated with the WDM LSP/ * Section 2.1 (three > > instances): s/for models
that supports both WSON and DWDM/for models > > that support both WSON and DWDM
flexible-grid/ * Section 2.1: s/label- > > restriction list represents
also/label-restriction list also represents/ * Section > > 2.1: > > s/The
label-step definition, […], are augmented/The label-step definition, > > […],
is augmented/ * Section 4: s/The "ietf-layer0-types" YANG module > > define/The
"ietf-layer0-types" YANG module defines/ > > > > A couple of slight rewrites
for clarity in Section 4: > > > > OLD > > These protocols have to use a secure
transport layer (e.g., SSH [RFC4252], TLS > > [RFC8446], and QUIC [RFC9000])
and have to use mutual authentication. > > > > NEW > > These protocols must use
a secure transport layer, such as SSH [RFC 4252], > > TLS [RFC 8446] or QUIC
[RFC 9000], and must use mutual authentication. > > > > (Also, you probably
want to reference I-D.ietf-tls-rfc8446bis instead of RFC > > 8446.) > > > > OLD
> > These nodes are intended to be reused by other YANG modules. The > >
modules by themselves do not expose any data nodes that are writable, > > data
nodes that contain read-only state, or RPCs. > > > > NEW > > These nodes are
designed for reuse by other YANG modules. The modules > > themselves do not
expose any writable data nodes, read-only state data > > nodes, or RPCs. > > >
> > > [Authors] The Security Considerations section was written using the
template provided in a previous version of draft-ietf-netmod-rfc8407bis. We
have aligned it with the template in draft-ietf-netmod-rfc8407bis-28. >