Dear Dale, Thank you for the review, the authors have updated the document to address your comments and posted the updated document as draft-ietf-ccamp-layer1-types-17 For clarity we have included the proposed resolution for each issue identified in the text below [Haomian & Italo]. Last month we received a YANG Doctors Review the latest version of the module (in v16), and have address several comments/suggestions made by Rob. Again, thanks for the support and review. Authors, Haomian and Italo. > -----Original Message----- > From: Dale Worley via Datatracker <noreply@xxxxxxxx> > Sent: giovedì 16 novembre 2023 22:16 > To: gen-art@xxxxxxxx > Cc: ccamp@xxxxxxxx; draft-ietf-ccamp-layer1-types.all@xxxxxxxx; last- > call@xxxxxxxx > Subject: [CCAMP] Genart last call review of draft-ietf-ccamp-layer1-types-16 > > Reviewer: Dale Worley > 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://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-ccamp-layer1-types-16 > Reviewer: Dale R. Worley > Review Date: 2023-11-16 > IETF LC End Date: 2023-11-21 > IESG Telechat date: [not known] > > Summary: > > This draft is basically ready for publication, but has nits that > should be fixed before publication. > > I recommend the Yang Doctors check the Yang module again. The last Yang > Doctor check was done on the -04 version, this is the -16 version, and the > Yang has changed considerably since then. > > Nits/editorial comments: > > Different parts of the text disagree on whether (1) this module is applicable > to all layer 1 networks, but is primarily expected to be used for OTN layer 1 > networks, or (2) is applicable to OTN layer networks. E.g. the two sentences > of the Abstract seem to take opposite approaches, sec. 4.1 seems to be OTN- > specific. Presumably the intention is agreed upon; the text needs to be > made consistent with the intention. > [Haomian & Italo] Ok, we see the need to be clearer in the Abstract, and Section 4.1. > 3. Prefix in Data Node Names > > +-------------+---------------------------+----------------------+ > | Prefix | YANG module | Reference | > +-------------+---------------------------+----------------------+ > | l1-types | ietf-layer1-types | This Document | > +-------------+---------------------------+----------------------+ > Table 1: Prefixes and Corresponding YANG Modules > > > RFC Editor Note: Please replace XXXX with the number assigned to the > RFC once this draft becomes an RFC. > > Should "This Document" be replaced by "RFC XXXX"? > [Haomian & Italo] Yes, updated. > 6. YANG Code for Layer1 Types > > identity ODU0 { > base odu-type; > description > "ODU0 type (1.24Gb/s)."; > > For "description" values that are not full sentences, there is inconsistency > whether the value ends with a period or not. There is also inconsistency in > values that are full sentences. (Perhaps this is a matter for the Editor.) > [Haomian & Italo] Ok, thanks. We have reviewed and used the current convention, and updated as needed. > Appendix A. Examples of OTN Label Ranges > > There are several instances of > > "//not-present tsg": "", > > I suspect they are intended to be > > "// not-present tsg": "", > [Haomian & Italo] Thanks, good catch as well. > [END] > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
