Re: [Last-Call] [CCAMP] Genart last call review of draft-ietf-ccamp-layer1-types-16

[Italo Busi <[e-mail]>]

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 <[e-mail]>
> Sent: giovedì 16 novembre 2023 22:16
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; last-
> [e-mail]
> 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]
> 
> 
>