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

["Daniele Ceccarelli (dceccare)" <[e-mail]>]

Hi Adrain,

Thanks for the thorough review and suggestions.

We were planning to move it forward as a cluster with the optical impairment draft, where some work is still needed but hopefully by the next IETF meeting should be ready.
What do you think, does it make sense as a plan? Or you'd suggest to split them and move RFC9093 bis faster?

Thanks
Daniele  

-----Original Message-----
From: CCAMP <[e-mail]> On Behalf Of Adrian Farrel
Sent: Monday, April 1, 2024 7:21 PM
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..."

---

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

---

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.

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.

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.

---

1.2

s/imported modules/imported module/

In the table tile, s/Prefixes/Prefix/  and s/modules/module/

---

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.

---

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.

---

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

---

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

---

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?

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

You don't say what "N" (or "n") is, presumably relying on the definition in 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 

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

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.

---

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

---




_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp