[CCAMP]Re: Are we nearly done with draft-ietf-ccamp-rfc9093-bis?

[Italo Busi <[e-mail]>]

Hi Adrian,

Thanks for your review and comments

We have just submitted an updated version draft-ietf-ccamp-rfc9093-bis-10 addressing your comments

See our feedbacks in line marked as [Authors]

Thanks again

Sergio and Italo (on behalf of co-authors/contributors)

> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: lunedì 1 aprile 2024 19:21
> To: [e-mail]
> Cc: [e-mail]
> Subject: [CCAMP] Are we nearly done with draft-ietf-ccamp-rfc9093-bis?
> 
> Hi,
> 
> I think this draft must be reaching completion, and I believe that it would be
> useful to hurry it along as the replacement to RFC 9093 so that new work can
> safely reference it.
> 
> I did a review and found a few nits. I know some of these existed in the 9093
> text, but we might polish as we go.
> 
> I hope this is helpful.
> 
> Cheers,
> Adrian
> 
> ===
> 
> Abstract
> 
> "These derived common types and groupings are intended..."
> 
> This is true, but a little terse for the Abstract because it doesn't say from what
> they are derived.
> 
> How about...
> 
> "These common types and groupings, derived from the built-in YANG data
> types, are intended..."
> 

[Authors] Done. Please note a similar text exists in RFC8776-bis and layer1-types: it may be worthwhile fixing also those I-Ds.

> ---
> 
> Abstract
> 
> "This document obsoletes RFC 9093."
> 
> Totally true, but doesn't give us a clue about the nature of the obsoletion. It
> could mark 9093 and all its types as deprecated, or it could (as it does) replace
> the document.
> 
> I suggest...
> 
> "This document obsoletes RFC 9093 by replacing the YANG module it
> contained with a new revision that includes additional YANG types."
> 

[Authors] Done

> ---
> 
> 1. Introduction
> 
>    This document adds new type definitions to the YANG modules and
>    obsoletes [RFC9093].  For further details, see the revision
>    statements of the YANG module in Section 4 or the summary in
>    Appendix A.
> 
> Several problems  ☹
> 
> a. Could use a little more explanation of the replacement of 9093. Something
> like...
> 
>    This document obsoletes [RFC9093] by replacing it in its entirety. It
>    provides a new revision of the YANG module contained in that RFC,
>    and retains the data types previously defined, but also adds new type
>    definitions to the YANG module.
> 

[Authors] Done

> b. The revision statements in the YANG module in Section 4 are pretty
>     unhelpful. They basically say "It was revised". I suggest to simply
>     drop the pointer to Section 4.
> 

[Authors] Done

> c. Appendix A is marked as "To be added in a future revision of this draft."
>     Obviously, that needs attention. I think that we have reached a level of
>     stability now where it should be pretty easy to fill in this section, and the
>     work is not much more than listing the new types that were added.
> 

[Authors] Done

> ---
> 
> 1.2
> 
> s/imported modules/imported module/
> 
> In the table tile, s/Prefixes/Prefix/  and s/modules/module/
> 

[Authors] Done

> ---
> 
> 1.2
> 
>    RFC Editor Note: Please replace XXXX with the RFC number assigned to
>    this document.
> 
> Please tell the RFC Editor to remove the note. E.g.,
> 
>    RFC Editor Note: Please replace XXXX with the RFC number assigned to
>    this document and remove this note.
> 

[Authors] Done

> ---
> 
> 2.
> 
> A number of entries in the list have:
>       TBD: add a description and a reference (also in YANG) or
>       TBD: add a description and the list of references defined in YANG
> 
> Clearly work to be done, but the relevant text seems to have been added to
> the YANG module, so it is only cut and paste that is needed.
> 

[Authors] Done

> ---
> 
> 2.
> 
> The last 7 or so entries in the list need to begin their text with a capital letter.
> 

[Authors] Done

> ---
> 
> 2.
> 
>    common-explicit-mode:
> 
>       a YANG grouping to define the list of attributes related to
>       optical impairments limits in case of transceiver explicit mode.
>       This grouping should be the same used in
>       [I-D.ietf-ccamp-dwdm-if-param-yang].
> 
> [snip]
> 
>    common-organizational-explicit-mode:
> 
>       a YANG grouping to define the common capabilities attributes limit
>       range in case of operational mode and explicit mode.  Also this
>       grouping should be used in [I-D.ietf-ccamp-dwdm-if-param-yang].
> 
> I don't think this document can tell the authors of draft-ietf-ccamp-dwdm-if-
> param-yang what to do, and the "should" carries no weight.
> It would be better to delete the two sentences that reference the other draft
> and, instead, send the authors of that draft an email (maybe copied to the
> CCAMP list).
> 

[Authors] Done

> ---
> 
> 2.
> 
> I think several descriptions in this section could usefully include a forward
> pointer to 2.1
> 

[Authors] Done

> ---
> 
> 2.1 has some terms that need to be expanded on first use:
> LSP
> OMS
> MCG
> 

[Authors] Done

> ---
> 
> 2.1
> 
> I am unclear of the benefit of quoting the formulae from RFC 6205. What
> would it mean if you made a misquote? Why can't you simply reference 6205?
> 

[Authors] It is very difficult to misquote a formula and to have the formula in the document is helping the reader for sure . We will add a sentence to justify the presence of the formula

> The formulae use "N" while RFC 6205 uses "n". Does this matter?
> 

[Authors] Changed "N" to "n" for complete alignment with RFC6205 and clarity

> You don't say what "N" (or "n") is, presumably relying on the definition in RFC
> 6205.
> 

[Authors] Added definition of "n" with reference to RFC 6205

> ---
> 
> 2.1
> 
> You also quote two formulae from RFC 7699. The problems are:
> 
> "SW = M x SWG (measured in GHz)" is not in 7699
> 

[Authors] Added definition of "n" with reference to RFC 7698

> SW, SWG, M and NCFG are not defined (7699 uses m not M)
> 

[Authors] Added reference also to RFC 7698

> As with 6205 you risk errors an possibly could just reference 7699 rather than
> quote the formula.
> 

[Authors] In this cases the formulas have been generalized to support finer granularity than the standard values with vendor-specific extensions. Text updated to clarify this

> ---
> 
> 2.1
> 
> You are using "x" for multiply which is understandable but diverges from 6205
> and 7699, and is possibly at variance with what the industry is used to.
> 

[Authors] Formulas updated to use '*' instead of 'x', in alignment with RFC 6205 and RFC 7699

> ---
> 
> 2.1
> 
>    The WDM Label Range is defined by the label-restriction list, defined
>    in [I-D.ietf-teas-rfc8776-update], which, for WDM, should be
>    augmented using the l0-label-range-info grouping (for WSON only
>    models) or the flexi-grid-label-range-info grouping (for DWDM
>    flexible-grid only models) or the wdm-label-range-info grouping (for
>    models that supports both WSON and DWDM flexible-grid).
> 
> The "should be augmented by..." has me confused.
> Are you saying "If there is a need to augment the label-restriction list defined
> in [I-D.ietf-teas-rfc8776-update] this should be done as follows...." ?
> 
> Similarly, a little later:
> 
>    The label-start and label-end definitions for WDM should be augmented
>    using the wson-label-start-end grouping (for WSON only models) or the
>    flexi-grid-label-start-end grouping (for DWDM flexible-grid only
>    models) or the wdm-label-start-end grouping (for models that supports
>    both WSON and DWDM flexible-grid).
> 
>    The label-step definition for WDM should be augmented using the wson-
>    label-step grouping (for WSON only models) or the flexi-grid-label-
>    step grouping (for DWDM flexible-grid only models) or the wdm-label-
>    step grouping (for models that supports both WSON and DWDM flexible-
>    grid).
> 

[Authors] Text rephrased to improve clarity

> ---
> 
> 2.1
> 
> You say that 7699 defines the attributes slot-width-granularity, min-slot-
> width-factor, max-slot-width-factor. I don't think it does.
> It may be helpful to say...
> 
>    In case of DWDM flexible grid, each entry in the label-restriction
>    list represents also the range of the supported slot width values
>    based on the following attributes, based on concepts used in
>    [RFC7699]:
> 

[Authors] Done

> ---
> 
> 
> 
> 
>