search

ietf-ccamp-wg / ietf-ccamp-layer0-types-ext-RFC9093-bis

CCAMP WG repository for ietf-layer0-types-ext
3 stars 3 forks source link

Comments from Adrian #98

Closed italobusi closed 1 month ago

italobusi commented 4 months ago

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

Sergio/Italo: Agreed. Please note a similar text exists in RFC8776-bis and layer1-types: it may be worthwhile fixing also those I-Ds. done

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

Sergio/Italo: Agreed. 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.

Sergio/Italo: Agreed. 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.

Sergio/Italo: Agreed.

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.

Sergio/Italo: Agreed. 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.

Sergio/Italo: Agreed. 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.

2.

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

Sergio/Italo: Agreed. 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).

Sergio/Italo: Agreed. done

2.

I think several descriptions in this section could usefully include a forward pointer to 2.1

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

Sergio/Italo: Agreed. 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> No difference, but we can change "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 > "n" is a two's-complement integer (positive, negative, or 0), we can report this sentence in the text

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>"m" is well defined in RFC7698 : "where 'm' is an integer greater than or equal to 1"

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

authors> RFC7698 section 3.2.1 report good definition , we can add this reference in the text.

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

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> ok we can use "*" as in the RFCs

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

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]:

See: https://mailarchive.ietf.org/arch/msg/ccamp/UsmlwB9rJEtscXVkXEUmnixPcUE/