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 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 > > 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 > > > > . > > > > 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. >