Common YANG Data Types for Layer 0 Optical Networks
draft-ietf-ccamp-rfc9093-bis-19

[Ballot comment]
Hi Sergio, Italo, Dieter, Esther, and Aihua,

Thank you for addressing my DISCUSS/COMMENT points [1] in -16 [2].

ACK for the note on the tree and I trust that you will make sure the broken tree is fixed during AUTH48.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/ccamp/cHYT2e77x4zVwqeP2t6EZxeivFc/

[2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-ccamp-rfc9093-bis-15&url2=draft-ietf-ccamp-rfc9093-bis-16&difftype=--html

[Ballot discuss]
Section 3, paragraph 1

Please be aware that a DISCUSS is just that. A discussion. That said, I want to DISCUSS several aspects of the module.

First of all, pyang gives the following error:
ietf-layer0-types@2025-02-25.yang:1: warning: unexpected latest revision "2025-06-06" in ietf-layer0-types@2025-02-25.yang, should be "2025-02-25"

which should be fixed.

My second point is whether this module has been tested. I understand that the module are mostly groupings, but have they been tested by including them in another module. I did a test by including some of the groupings inside of a container in a file called x.yang. Granted, this is a brute force method. Maybe there are expectations that multiple groupings will not be inherited by other modules, and maybe if they are done, then some of these error messages will go away. However, some of the errors are not related to the hierarchy of the groupings. If this has been done, great. If not, without some testing I would feel queasy at best.

Here is the sample x.yang file I am using.
module x {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:x";
  prefix x;
  import ietf-layer0-types {
    prefix l0-types;
  }
  container x {
    uses l0-types:wdm-label-start-end;
    uses l0-types:wdm-label-step;
    uses l0-types:wdm-label-hop;
    uses l0-types:wdm-label-range-info;
    uses l0-types:wson-label-start-end;
    uses l0-types:wson-label-hop;
    uses l0-types:l0-label-range-info;
    uses l0-types:wson-label-step;
    uses l0-types:flexi-grid-label-start-end;
    uses l0-types:flexi-grid-frequency-slot;
    uses l0-types:flexi-grid-frequency-slot;
    uses l0-types:flexi-grid-label-hop;
  }
}

When compiled using pyang, here is the error I get:

x.yang:13: error: there is already a child node to "x" at x.yang:10 with the name "grid-type" defined at x.yang:11 (at ietf-layer0-types@2025-02-25.yang:925)
x.yang:13: error: there is already a child node to "x" at x.yang:10 with the name "dwdm-n" defined at x.yang:11 (at ietf-layer0-types@2025-02-25.yang:929)
x.yang:13: error: there is already a child node to "x" at x.yang:10 with the name "cwdm-n" defined at x.yang:11 (at ietf-layer0-types@2025-02-25.yang:945)
x.yang:13: error: there is already a child node to "x" at x.yang:10 with the name "flexi-n" defined at x.yang:11 (at ietf-layer0-types@2025-02-25.yang:1318)

Again, this might be because 'grid-type' may not be expected to be included from both the groupings 'wdm-label-start-end' as well as 'wdm-label-hop'.

But this error might be related to the use of \. See comment below.

x.yang:11 (at ietf-layer0-types@2025-02-25.yang:931): error: the path has too many ".."
x.yang:11 (at ietf-layer0-types@2025-02-25.yang:947): error: the path has too many ".."
Also, indentation is off in several places in the file. Please fix them. For base identities please update the description to say "Base identity for ...".

Section 3, paragraph 92
>      typedef standard-mode {
>        type string;
>        description
>          "Identifies an ITU-T G.698.2 standard application code.
>
>          It MUST be a string with a format that follows the
>          nomenclature defined in section 5.3 of ITU-T G.698.2.";
>        reference
>          "ITU-T G.698.2 (11/2018)";
>      }

If the string has a nomenclature, why is there no 'pattern' statement to make sure it meets that nomenclature?

Section 3, paragraph 115
>          case fixed-dwdm {
>            leaf dwdm-n {
>              when "derived-from-or-self(../../../grid-type,
>                    \"wson-grid-dwdm\")" {
>                description
>                  "Valid only when grid type is DWDM.";
>              }

Use the following format to define the 'when' statement and get rid of the \ here and anywhere you use the 'when' statement. It is opposite of how single quotes and double quotes have been used in the current draft.

when 'derived-from-or-self(type, "exif:fast-ethernet");

[Ballot comment]
Section 1, paragraph 0
>    YANG [RFC7950] is a data modeling language used to model
>    configuration data, state data, Remote Procedure Calls, and
>    notifications for network management protocols such as the Network
>    Configuration Protocol (NETCONF) [RFC6241].  The YANG language
>    supports a small set of built-in data types and provides mechanisms
>    to derive other types from the built-in types.

This paragraph is redundant and should be removed.

Section 1.2, paragraph 5

Even though this document defines groupings, and there is one big tree diagram in the Appendix, it would have been nice to include snippets of the big groupings in the form of a tree diagram here along with the description to help explain some of the content.

Section 3, paragraph 14
>        description
>          "To be updated";

Please update in that case :-)

Section 3, paragraph 16
>        description
>          "Layer 0 grid type";

This is one example of a base identity. In this case, it should say "Base identity for Layer 0 grid type".

Section 3, paragraph 17
>          description
>            "CWDM grid";

Considering that the YANG module will be separated from this document where some of these acronnyms are defined, all acromyms should be expanded.

Section 3, paragraph 45
>        identity DPSK {
>          base modulation;
>          description
>            "DPSK (Differential Phase Shift Keying) modulation";
>        }

Are there no references for the modulation types?

Section 3, paragraph 64
>      identity line-coding {
>        description
>          "Base identity to defined the bit rate/line coding of optical
>          tributary signals.";
>        reference
>          "Section 7.1.2 of ITU-T G.698.2 v3.0 (11/2018).";
>      }

Indentation is off. And thanks for identifying it as a base identity.

Section 3, paragraph 69
>      identity wavelength-assignment {
>        description
>          "Wavelength selection base";
>        reference
>          "RFC 7689: Signaling Extensions for Wavelength Switched
>          Optical Networks";
>      }

Indentation is off. And while the word base is there, better to word it as "Base identity for wavelength selection".

Section 3, paragraph 78
>      typedef dwdm-n {
>        type int16;

Can dwdm-m have a negative value for N? And is there a range for the value 'N'?

Section 3, paragraph 80
>      typedef cwdm-n {
>        type int16;

Same comment here.

Section 3, paragraph 92
>    // RFC Ed.: replace YYYY with actual RFC number and remove
>    // this note after draft-ietf-ccamp-optical-impairment-topology-yang
>    // is published as an RFC

Can all instructions to the RFC Editor be consolidated in one place?

Section 3, paragraph 97
>      typedef fiber-type {
>        type enumeration {
>          enum G.652 {
>            description
>              "G.652 Standard Singlemode Fiber";
>          }
>          enum G.654 {
>            description
>              "G.654 Cutoff Shifted Fiber";
>          }
>          enum G.653 {
>            description "G.653 Dispersion Shifted Fiber";
>          }
>          enum G.655 {
>            description "G.655 Non-Zero Dispersion Shifted Fiber";
>          }
>          enum G.656 {
>            description
>              "G.656 Non-Zero Dispersion for Wideband Optical Transport";
>          }
>          enum G.657 {
>            description
>              "G.657 Bend-Insensitive Fiber";
>          }
>        }
>        description
>          "ITU-T based fiber-types";
>      }

Reference please.

Section 3, paragraph 115
>      grouping wdm-label-hop {
>        description
>          "Generic label-hop information for fixed & flexi-DWDM or
>          CWDM grid";
>        choice grid-type {
>          description
>            "Label for DWDM or CWDM grid";
>          case fixed-dwdm {
>            choice fixed-single-or-super-channel {
>              description
>                "single or super channel";
>              case single {
>                leaf dwdm-n {
>                  type dwdm-n;
>                  description
>                    "The given value 'N' is used to determine the
>                    nominal central frequency.";
>                }
>              }
>              case multi {
>                leaf-list subcarrier-dwdm-n {
>                  type dwdm-n;
>                  min-elements 2;
>                  description
>                    "The given values 'N' are used to determine the
>                    nominal central frequency for each subcarrier
>                    channel.";
>                  reference
>                    "ITU-T G.694.1 (10/2020): Spectral grids for WDM
>                    applications: DWDM frequency grid";
>                }
>              }
>            }
>          }

Which one of this is an option for flexi-DWDM? Can it be identified?
Also, I see multiple terms here that have not been explained. 'super-channel', 'flexi-DWDM', 'multi'.

Section 3, paragraph 118
>      grouping wson-label-start-end {
>        description
>          "The WSON label-start or label-end used to specify WSON label
>          range.";
>        choice grid-type {
>          description
>            "Label for DWDM or CWDM grid";
>          case dwdm {
>            leaf dwdm-n {
>              when "derived-from-or-self(../../../grid-type,
>                    \"wson-grid-dwdm\")" {
>                description
>                  "Valid only when grid type is DWDM.";
>              }
>              type dwdm-n;
>              description
>                "The central frequency of DWDM.";
>              reference
>                "RFC 6205: Generalized Labels for Lambda-Switch-Capable
>                (LSC) Label Switching Routers";
>            }
>          }
>          case cwdm {
>            leaf cwdm-n {
>              when "derived-from-or-self(../../../grid-type,
>                    \"wson-grid-cwdm\")" {
>                description
>                  "Valid only when grid type is CWDM.";
>              }
>              type cwdm-n;
>              description
>                "Channel wavelength computing input.";
>              reference
>                "RFC 6205: Generalized Labels for Lambda-Switch-Capable
>                (LSC) Label Switching Routers";
>            }
>          }
>        }
>        reference
>          "RFC 6205: Generalized Labels for Lambda-Switch-Capable (LSC)
>          Label Switching Routers";
>      }

Where is label-start and label-end in this grouping?

Section 3, paragraph 118
>              case single {
>                leaf dwdm-n {
>                  type dwdm-n;
>                  description
>                    "The given value 'N' is used to determine the
>                    nominal central frequency.";
>                }
>              }

Reference please.

Section 3, paragraph 121
>      grouping flexi-grid-label-start-end {
>        description
>          "The flexi-grid label-start or label-end used to specify
>          flexi-grid label range.";
>        leaf flexi-n {
>          type flexi-n;
>          description
>            "The given value 'N' is used to determine the nominal
>            central frequency.
>
>            As described in section 3.1 of RFC 8363, the range of
>            available nominal central frequencies are advertised for
>            m=1, which means that for an available central frequency n,
>            the frequency slot from central frequency n-1 to central
>            frequency n+1 is available.";
>        }
>        reference
>          "RFC 7699: Generalized Labels for the Flexi-Grid in Lambda
>          Switch Capable (LSC) Label Switching Routers,
>
>          RFC 8363: GMPLS OSPF-TE Extensions in Support of Flexi-Grid
>          Dense Wavelength Division Multiplexing (DWDM) Networks";
>      }

The description and name of the grouping does not seem to jive with the contents of the grouping. How is this a lable-start-end if there is only one leaf with a description that says "The given value 'N' is used to determine the nominal central frequency"? Can this be described in a way that indicates a start and an end?

Section 3, paragraph 132
>        container supported-modes {
>          presence
>            "When present, it indicates that the modes supported by a
>            transceiver are reported.";
>          config false;
>          description
>            "The top level container for the list supported
>            transceiver's modes.";

If your overall container is 'config false', you do not need to specify 'config false' at every container, list and leaf level. Please remove. As an example, see below.

Section 3, paragraph 141
>        list cd-penalty {
>          key cd-value;
>          config false;
>          description
>            "Optional penalty associated with a given accumulated
>            chromatic dispersion (CD) value measured in
>            absence of other impairments.
>
>            This list of pair CD and OSNR penalty can be used to
>            sample the function OSNR penalty = f(CD).";
>          leaf cd-value {
>            type decimal-2;
>            units "ps/nm";
>            config false;
>            mandatory true;
>            description
>              "The Chromatic Dispersion (CD).";
>          }
>          uses penalty-value;
>          reference
>            "Section 2.6.4 of RFC YYYY: A YANG Data Model for Optical
>            Impairment-aware Topology.";
>        }

You have the overall list as 'config false'. Why do you need 'config false' to be specified under the leaf 'cd-value'? Same comment applies to other config false lists.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.666]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.709.3]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.709]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [OIF_400ZR]. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.975]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.975.1]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.977.1]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.694.1]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.694.2]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.709.2]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.959.1]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.9700]. If so, the
IESG needs to approve it.

Possible DOWNREF from this Standards Track doc to [ITU-T_G.698.2]. If so, the
IESG needs to approve it.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 58
> ng { description "Base identity to defined the bit rate/line coding of optica
>                                    ^^^^^^^
The verb after "to" should be in the base form as part of the to-infinitive. A
verb can take many forms, but the base form is always used in the
to-infinitive.

"Reference", paragraph 23
> mplate with the proper XPath which depends from where this grouping is actual
>                                    ^^^^^^^
The verb "depend" requires the preposition "on" (or "upon").

"Reference", paragraph 26
> rantees interoperability. It must be an string with the following format: B-
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

"Reference", paragraph 38
> icates the transceiver frequency fine tuning granularity e.g 3.125GHz or 0.00
>                                  ^^^^^^^^^^^
This word is normally spelled with a hyphen.

"Reference", paragraph 42
> nels. It is applicable only to multi-channel modes."; } } // grouping common
>                                ^^^^^^^^^^^^^
This word is normally spelled as one.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ccamp-rfc9093-bis-15
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Daniele Ceccarelli for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Title

Please add "optical" in the title as the content is "only" about optical layer-0. Section 1.1 indicates the "limited" scope but it should be refleted in the title as well.

### Appendix A

Even when the tree is long, I prefer to have it in the middle part of the I-D not as an appendix. But, I guess that this is a matter of taste.

[Ballot discuss]
Hi Sergio, Italo, Dieter, Esther, and Aihua,

Thank you for the effort put into this bis document.

Only main comments are enclosed here. I will send you a link with a more comprehensive review. Feel free to grab whatever useful for you from that link.

# DISCUSS

## Lack of an Operational Considerations section that discuss the implications (or lack of) deprecated parameters.

Please add such section with the listed of deprecated parameters.

## (in)Adequate provision for extensibility

Do we expect those to evolve?

CURRENT:
  typedef fiber-type {
    type enumeration {
      enum G.652 {
        description
          "G.652 Standard Singlemode Fiber";
      }
      enum G.654 {
        description
          "G.654 Cutoff Shifted Fiber";
      }
      enum G.653 {
        description "G.653 Dispersion Shifted Fiber";
      }
      enum G.655 {
        description "G.655 Non-Zero Dispersion Shifted Fiber";
      }
      enum G.656 {
        description
          "G.656 Non-Zero Dispersion for Wideband Optical Transport";
      }
      enum G.657 {
        description
          "G.657 Bend-Insensitive Fiber";
      }
    }
    description
      "ITU-T based fiber-types";
      "ITU-T based fiber-types";
  }

As a reminder RRC8407bis says:

  If the set of values is fixed and the data type contents are
  controlled by a single naming authority (e.g., IANA), then an
  enumeration data type SHOULD be used.

  If distributed extensibility or hierarchical organization of
  enumerated values is required, then the "identityref" data type
  SHOULD be used instead of an enumeration or other built-in type.
 
BTW, are there references to cite here?

## Missing prefix in many places. For example:

CURRENT:
      case fixed-dwdm {
        leaf dwdm-n {
          when "derived-from-or-self(../../../grid-type,
                \"wson-grid-dwdm\")" {

8407bsi says:
  XPath expressions that contain a literal value representing a YANG
  identity SHOULD always include the declared prefix of the module
  where the identity is defined.

As I’m there, you may also use “+” for folding. You may consider:

NEW:
      case fixed-dwdm {
        leaf dwdm-n {
          when "derived-from-or-self(../../../grid-type, "
              + "l0-types:wson-grid-dwdm)" {

Please fix other similar issues.

## Make sure the default will be needed for all cases

CURRENT:
      leaf min-slot-width-factor {
        type uint16 {
          range "1..max";
        }
        default "1";

As a reminder, RFC8407bis says the following:

  *  Do not include a "default" substatement on a leaf or choice unless
      the value applies on all possible contexts.

The default values can be a hinderance for templates/profiles. Please make sure this is intended.

The comment applies for similar statement in the module.

## Case+When constructs. For example,

CURRENT:
      case dwdm {
        leaf dwdm-n {
          when "derived-from-or-self(../../../grid-type,
                \"wson-grid-dwdm\")" {
            description
              "Valid only when grid type is DWDM.";
          }

May be transformed to a container if you want to keep the when clause. Please check that you are following RFC8407bis:

  Some modules use "case + when" construct but provide duplicated
  information (e.g., the "when" statements are constraining a single
  case in the choice as shown in the example below).  Such constructs
  with duplicated information SHOULD NOT be used.

## Are we sure config is used to comply with 8407

CURRENT:
    leaf standard-mode {
      type standard-mode;
      config false;

RFC8407bis has the following:
  *  Do not include a "config" substatement on a data node unless the
      value applies on all possible contexts.

## Normative dependency on an obsoleted RFC


6.1.  Normative References

..
  [RFC9093]  Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A
              YANG Data Model for Layer 0 Types", RFC 9093,
              DOI 10.17487/RFC9093, August 2021,
              .

6.2.  Informative References


Please move 9093 to be listed as Informative.

[Ballot discuss]
Hi Sergio, Italo, Dieter, Esther, and Aihua,

Thank you for the effort put into this bis document.

Only main comments are enclosed here. I will send you a link with a more comprehensive review. Feel free to grab whatever useful for you from that link.

# DISCUSS

## Lack of an Operational Considerations section that discus the implications (or lack of) deprecated parameters.

Please add such section with the listed of deprecated parameter.

## (in)Adequate provisions for extensibility

Do we expect those to evolve?

CURRENT:
  typedef fiber-type {
    type enumeration {
      enum G.652 {
        description
          "G.652 Standard Singlemode Fiber";
      }
      enum G.654 {
        description
          "G.654 Cutoff Shifted Fiber";
      }
      enum G.653 {
        description "G.653 Dispersion Shifted Fiber";
      }
      enum G.655 {
        description "G.655 Non-Zero Dispersion Shifted Fiber";
      }
      enum G.656 {
        description
          "G.656 Non-Zero Dispersion for Wideband Optical Transport";
      }
      enum G.657 {
        description
          "G.657 Bend-Insensitive Fiber";
      }
    }
    description
      "ITU-T based fiber-types";
      "ITU-T based fiber-types";
  }

As a reminder RRC8407bis says:

  If the set of values is fixed and the data type contents are
  controlled by a single naming authority (e.g., IANA), then an
  enumeration data type SHOULD be used.

  If distributed extensibility or hierarchical organization of
  enumerated values is required, then the "identityref" data type
  SHOULD be used instead of an enumeration or other built-in type.
 
BTW, are there references to cite here?

## Missing prefix in many places. For example:

CURRENT:
      case fixed-dwdm {
        leaf dwdm-n {
          when "derived-from-or-self(../../../grid-type,
                \"wson-grid-dwdm\")" {

8407bsi says:
  XPath expressions that contain a literal value representing a YANG
  identity SHOULD always include the declared prefix of the module
  where the identity is defined.

As I’m there, you may also use “+” for folding. You may consider:

NEW:
      case fixed-dwdm {
        leaf dwdm-n {
          when "derived-from-or-self(../../../grid-type, "
              + "l0-types:wson-grid-dwdm)" {

Please fix other similar issues.

## Make sure the default will be needed for all cases

CURRENT:
      leaf min-slot-width-factor {
        type uint16 {
          range "1..max";
        }
        default "1";

As a reminder, RFC8407bis says the following:

  *  Do not include a "default" substatement on a leaf or choice unless
      the value applies on all possible contexts.

The default values can be a hinderance for templates/profiles. Please make sure this is intended.

The comment applies for similar statement in the module.

## Case+When constructs. For example,

CURRENT:
      case dwdm {
        leaf dwdm-n {
          when "derived-from-or-self(../../../grid-type,
                \"wson-grid-dwdm\")" {
            description
              "Valid only when grid type is DWDM.";
          }

May be transformed to a container if you want to keep the when clause. Please check that you are following RFC8407bis:

  Some modules use "case + when" construct but provide duplicated
  information (e.g., the "when" statements are constraining a single
  case in the choice as shown in the example below).  Such constructs
  with duplicated information SHOULD NOT be used.

## Are we sure config is used to comply with 8407

CURRENT:
    leaf standard-mode {
      type standard-mode;
      config false;

RFC8407bis has the following:
  *  Do not include a "config" substatement on a data node unless the
      value applies on all possible contexts.

## Normative dependency on an obsoleted RFC


6.1.  Normative References

..
  [RFC9093]  Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A
              YANG Data Model for Layer 0 Types", RFC 9093,
              DOI 10.17487/RFC9093, August 2021,
              .

6.2.  Informative References


Please move 9093 to be listed as Informative.

[Ballot comment]
# Please consider organizing “2. Layer 0 Types Module Contents” into subsections to better present the typedefs, identities, groupings. These are currently mixed without any structure, which is not convenient to walk through.

# Indentation is not consistent in the module. Please run "pyang -f yang --yang-canonical" or similar

# Follow the IETF template in 8407bis. For example, add this missing to the description part

    All revisions of IETF and IANA published modules can be found
    at the YANG Parameters registry group
    (https://www.iana.org/assignments/yang-parameters).

# Use the exact document title, when cited

OLD: "RFC XXXX: A YANG Data Model for Layer 0 Types";
NEW: "RFC XXXX: Common YANG Data Types for Layer 0 Networks";

# Please list the changes vs. 9093. Refer to 8407bis for guidance

CURRENT:
  revision 2025-06-06 {
    description
      "To be updated";

# Consider use better and meaningful descriptions. For example, the following description does not say much about this.

CURRENT:
  identity l0-grid-type {
    description
      "Layer 0 grid type";

Or

  description "ID for the supported transceiver's mode.";

There are many such issues in the module.

Likewise, there are many descriptions that I don’t parse. For example;

CURRENT:
        "organization identifier that uses organizational
        mode";

# Expand on first use. For example,

CURRENT:
    identity wson-grid-cwdm {
      base l0-grid-type;
      description
        "CWDM grid";

# Provide explicit pointers for the references to be useful and convenient for readers. For example,

OLD:
    identity cwdm-20nm {
      base cwdm-ch-spc-type;
      description
        "20nm channel spacing";
      reference
        "RFC 6205: Generalized Labels for Lambda-Switch-Capable (LSC)
        Label Switching Routers,

NEW:
    identity cwdm-20nm {
      base cwdm-ch-spc-type;
      description
        "20nm channel spacing.";
      reference
        "RFC 6205: Generalized Labels for Lambda-Switch-Capable (LSC)
                  Label Switching Routers, Section 3.1

Or

OLD:
  identity dwdm-ch-spc-type {
    description
      "DWDM channel-spacing type";
    reference
      "RFC 6205: Generalized Labels for Lambda-Switch-Capable (LSC)
      Label Switching Routers,

      ITU-T G.694.1 (10/2020): Spectral grids for WDM applications:
      DWDM frequency grid";

NEW:
  identity dwdm-ch-spc-type {
    description
      "DWDM channel-spacing type.";
    reference
      "RFC 6205: Generalized Labels for Lambda-Switch-Capable (LSC)
                Label Switching Routers, Section 3
      ITU-T G.694.1 (10/2020): Spectral grids for WDM applications:
                DWDM frequency grid";


Etc.

BTW, use consistent formatting for the reference statements.

OLD:
      "Section 3 of RFC 7688: GMPLS OSPF Enhancement for Signal and
      Network Element Compatibility for Wavelength Switched Optical
      Networks";

NEW:
      "RFC 7688: GMPLS OSPF Enhancement for Signal and
                Network Element Compatibility for Wavelength Switched Optical
                Networks, Section 3";

# Consistently expand your acronyms. For example,

OLD: "DPSK (Differential Phase Shift Keying) modulation";
NEW: "Differential Phase Shift Keying (DPSK) modulation.";

OLD: "QPSK (Quadrature Phase Shift Keying) modulation";
NEW: "Quadrature Phase Shift Keying (QPSK) modulation.";

# Check your use of identifiers with uppercase. For example,

CURRENT:
  identity line-coding-NRZ-2p5G { 

  …

    identity line-coding-NRZ-OTU1 {
  etc.

8407bis has the following:

  Identifiers SHOULD follow a consistent naming pattern throughout the
  module.  Only lowercase letters, numbers, and dashes SHOULD be used
  in identifier names. Uppercase characters, the period character, and
  the underscore character MAY be used if the identifier represents a
  well-known value that uses these characters.

# RFC YYYY is used to refer to two distinct documents. Suggest to fix this to avoid confusion:

OLD:
      "Section 2.5.2 of RFC YYYY: A YANG Data Model for Optical
      Impairment-aware Topology.";
  }
// RFC Ed.: replace YYYY with actual RFC number and remove
// this note after draft-ietf-ccamp-optical-impairment-topology-yang
// is published as an RFC

NEW:
      "RFC IIII: A YANG Data Model for Optical Impairment-aware
                Topology, Section 2.5.2";
  }
// RFC Ed.: replace IIII with actual RFC number and remove
// this note after draft-ietf-ccamp-optical-impairment-topology-yang
// is published as an RFC

# Can this be enforced by YANG statement (pattern)?

CURRENT:
  typedef standard-mode {
    type string;
    description
      "Identifies an ITU-T G.698.2 standard application code.

      It MUST be a string with a format that follows the     
      nomenclature defined in Section 5.3 of ITU-T G.698.2.";

If not, consider at least including the constraint in the description rather that via indirect citation.

# I guess you meant multi rather than super. There is no valid "super" node in the wdm-label-hop grouping:

CURRENT:
      case fixed-dwdm {
        choice fixed-single-or-super-channel {
          description
            "single or super channel";

Please consider using a more descriptive text.

# Redundant with default values. For example,

CURRENT:
        default "flexi-swg-12p5ghz";
        description
          "Minimum space between slot widths. Default is 12.500

If you maintain the default statement, the default part of the description is redundant. Please keep one.

# Redundant with the reference statement. For example:

OLD:
        This attribute is also known as central frequency
        granularity in RFC 8363.";
      reference
        "RFC 8363: GMPLS OSPF-TE Extensions in Support of Flexi-Grid
        Dense Wavelength Division Multiplexing (DWDM) Networks";

NEW:
        This attribute is also known as central frequency
        granularity.";
      reference
        "RFC 8363: GMPLS OSPF-TE Extensions in Support of Flexi-Grid
                  Dense Wavelength Division Multiplexing (DWDM) Networks";

# The following are not normative, please move them to be listed as Informative:

  [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              .

  [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              .

# List keys are mandatory. Please fix the tree diagram

OLD:
            |  +-- flexi-m?              flexi-m
            x--:(super)
            |  x-- subcarrier-flexi-n* [flexi-n]
            |    +-- flexi-n    flexi-n
            |    +-- flexi-m?  flexi-m
            +--:(multi)
                +-- frequency-slots
                  +-- frequency-slot* [flexi-n]
                      +-- flexi-n    flexi-n
                      +-- flexi-m?  flexi-m
  grouping wdm-label-range-info:
    +-- grid-type?    identityref
      …
      |  +-- flexi-m?              flexi-m
      x--:(super)
      |  x-- subcarrier-flexi-n* [flexi-n]
      |    +-- flexi-n?  flexi-n
      |    +-- flexi-n    flexi-n
      |    +-- flexi-m?  flexi-m
      +--:(multi)
          +-- frequency-slots
            +-- frequency-slot* [flexi-n]
                +-- flexi-n    flexi-n
                +-- flexi-m?  flexi-m
  grouping flexi-grid-label-range-info:
    +-- grid-type?    identityref
    …
  grouping transceiver-capabilities:
    +--ro supported-modes!
      +--ro supported-mode* [mode-id]
          +--ro mode-id                          string
          +--ro (mode)
            +--:(G.698.2)
            |  +--ro standard-mode?              standard-mode


NEW:
            |  +-- flexi-m?              flexi-m
            x--:(super)
            |  x-- subcarrier-flexi-n* [flexi-n]
            |    +-- flexi-n    flexi-n
            |    +-- flexi-m?  flexi-m
            +--:(multi)
                +-- frequency-slots
                  +-- frequency-slot* [flexi-n]
                      +-- flexi-n    flexi-n
                      +-- flexi-m?  flexi-m
  grouping wdm-label-range-info:
    +-- grid-type?    identityref
…
      |  +-- flexi-m?              flexi-m
      x--:(super)
      |  x-- subcarrier-flexi-n* [flexi-n]
      |    +-- flexi-n    flexi-n
      |    +-- flexi-m?  flexi-m
      +--:(multi)
          +-- frequency-slots
            +-- frequency-slot* [flexi-n]
                +-- flexi-n    flexi-n
                +-- flexi-m?  flexi-m
  grouping flexi-grid-label-range-info:
    +-- grid-type?    identityref 
    …
  grouping transceiver-capabilities:
    +--ro supported-modes!
      +--ro supported-mode* [mode-id]
          +--ro mode-id                          string
          +--ro (mode)
            +--:(G.698.2)
            |  +--ro standard-mode?              standard-mode

Hope this helps.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ccamp-rfc9093-bis-15. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

an existing namespace will have its reference updated:

ID: yang:ietf-layer0-types
URI: urn:ietf:params:xml:ns:yang:ietf-layer0-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

We will initiate the required Expert Review via a separate request. Expert review will need to be completed before the document can be marked as IANA OK.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

a new, updated YANG module will be registered as follows:

Name: ietf-layer0-types
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-layer0-types
Prefix: l0-types
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-06-23):

From: The IESG
To: IETF-Announce
CC: ccamp-chairs@ietf.org, ccamp@ietf.org, dceccare@cisco.com, draft-ietf-ccamp-rfc9093-bis@ietf.org, ketant.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Common YANG Data Types for Layer 0 Networks) to Proposed Standard


The IESG has received a request from the Common Control and Measurement Plane
WG (ccamp) to consider the following document: - 'Common YANG Data Types for
Layer 0 Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-06-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a collection of common data types, identities,
  and groupings in the YANG data modeling language.  These common types
  and groupings, derived from the built-in YANG data types, identities,
  and groupings are intended to be imported by modules that model
  Optical Layer 0 configuration and state capabilities, such as
  Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense
  Wavelength Division Multiplexing (DWDM) networks.

  This document obsoletes RFC 9093 by replacing the YANG module it
  contained with a new revision that includes additional YANG data
  types, identities and groupings.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc9093-bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-teas-rfc8776-update: Common YANG Data Types for Traffic Engineering (None - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

-The document has very wide support in the working group. The working group last call of a document depending on this one has raised the need to update this document as well. The document has been sent back to the WG, modifications been done and a second WG last call performed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

- No controversy. The chairs and the working group agreed on the need for a bis.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

- No threat.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-We didn't investigate, but all the major vendors in the area are involved in this work.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
- No. the document has some linkage with the TE types work in TEAS but the leading authors are the same and the two works are absolutely aligned.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
- Routing directorate review done (ready), YANG doctor review done (Ready with issues) and all the issues have been addressed by the authors.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
- 0 errors/warnings reported (in addition to YANG doctor review).

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
- see above

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
- Yes. The working group has been working on RFC 9093 deliberately leaving some issues to be addressed in the BIS (as requested by the chairs). The document is now complete and clearly written.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
- Security considerations for routing protocols and architectures, and Operational and management considerations

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
- Proposed standard. This is the proper type of RFC and all the attributes reflect it.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
- Yes. IPR polling running at WG adoption and WG last call. All IPR declarations collected and stored in the WG WIKI and in the history of the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
- Yes. Number of front page authors reduced to five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
- No ID nits found during the review.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
- All references are correctly indicated.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
- All of the external references are freely reachable.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
- No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
- No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
- The draft is a standard BIS document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
- The document requests to update URIs and registries in alignment with the content of the rest of the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
- The document requests to "register" the ietf-layer0-types module in the "YANG Module Names" registry [RFC6020] within the "YANG
  Parameters" registry group. Such module already exists as it was created for RFC9093. SHould the draft be updated to ask for it's update instead of registration?

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

-The document has very wide support in the working group. The working group last call of a document depending on this one has raised the need to update this document as well. The document has been sent back to the WG, modifications been done and a second WG last call performed.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

- No controversy. The chairs and the working group agreed on the need for a bis.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

- No threat.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-We didn't investigate, but all the major vendors in the area are involved in this work.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
- No. the document has some linkage with the TE types work in TEAS but the leading authors are the same and the two works are absolutely aligned.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
- Routing directorate review done (ready), YANG doctor review done (Ready with issues) and all the issues have been addressed by the authors.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
- 0 errors/warnings reported (in addition to YANG doctor review).

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
- see above

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
- Yes. The working group has been working on RFC 9093 deliberately leaving some issues to be addressed in the BIS (as requested by the chairs). The document is now complete and clearly written.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
- Security considerations for routing protocols and architectures, and Operational and management considerations

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
- Proposed standard. This is the proper type of RFC and all the attributes reflect it.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
- Yes. IPR polling running at WG adoption and WG last call. All IPR declarations collected and stored in the WG WIKI and in the history of the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
- Yes. Number of front page authors reduced to five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
- No ID nits found during the review.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
- All references are correctly indicated.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
- All of the external references are freely reachable.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
- No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
- No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
- The draft is a standard BIS document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
- The document requests to update URIs and registries in alignment with the content of the rest of the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
- The document requests to "register" the ietf-layer0-types module in the "YANG Module Names" registry [RFC6020] within the "YANG
  Parameters" registry group. Such module already exists as it was created for RFC9093. SHould the draft be updated to ask for it's update instead of registration?

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Since this document needs to be updated (per discussion at the Feb 17, 2025 ccamp interim) I'm returning it to the WG. It can come back to Publication Requested just as soon as the WG thinks it is ready (could be quickly).

Since this document needs to be updated (per discussion at the Feb 17, 2025 ccamp interim) I'm returning it to the WG. It can come back to Publication Requested just as soon as the WG thinks it is ready (could be quickly).

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

-The document has very wide support in the working group

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

- No controversy. The chairs and the working group agreed on the need for a bis.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

- No threat.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-We didn't investigate, but all the major vendors in the area are involved in this work.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
- No. the document has some linkage with the TE types work in TEAS but the leading authors are the same and the two works are absolutely aligned.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
- Routing directorate review done (ready), YANG doctor review done (Ready with issues) and all the issues have been addressed by the authors.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
- 0 errors/warnings reported (in addition to YANG doctor review).

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
- see above

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
- Yes. The working group has been working on RFC 9093 deliberately leaving some issues to be addressed in the BIS (as requested by the chairs). The document is now complete and clearly written.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
- Security considerations for routing protocols and architectures, and Operational and management considerations

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
- Proposed standard. This is the proper type of RFC and all the attributes reflect it.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
- Yes. IPR polling running at WG adoption and WG last call. All IPR declarations collected and stored in the WG WIKI and in the history of the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
- Yes. Number of front page authors reduced to five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
- No ID nits found during the review.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
- All references are correctly indicated.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
- All of the external references are freely reachable.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
- No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
- No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
- The draft is a standard BIS document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
- The document requests to update URIs and registries in alignment with the content of the rest of the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
- The document requests to "register" the ietf-layer0-types module in the "YANG Module Names" registry [RFC6020] within the "YANG
  Parameters" registry group. Such module already exists as it was created for RFC9093. SHould the draft be updated to ask for it's update instead of registration?

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

-The document has very wide support in the working group

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

- No controversy. The chairs and the working group agreed on the need for a bis.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

- No threat.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
-We didn't investigate, but all the major vendors in the area are involved in this work.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
- No. the document has some linkage with the TE types work in TEAS but the leading authors are the same and the two works are absolutely aligned.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
- Routing directorate review done (ready), YANG doctor review done (Ready with issues) and all the issues have been addressed by the authors.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
- 0 errors/warnings reported (in addition to YANG doctor review).

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
- see above

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
- Yes. The working group has been working on RFC 9093 deliberately leaving some issues to be addressed in the BIS (as requested by the chairs). The document is now complete and clearly written.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
- Security considerations for routing protocols and architectures, and Operational and management considerations

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
- Proposed standard. This is the proper type of RFC and all the attributes reflect it.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
- Yes. IPR polling running at WG adoption and WG last call. All IPR declarations collected and stored in the WG WIKI and in the history of the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
- Yes. Number of front page authors reduced to five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
- No ID nits found during the review.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
- All references are correctly indicated.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
- All of the external references are freely reachable.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
- No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
- No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
- The draft is a standard BIS document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
- The document requests to update URIs and registries in alignment with the content of the rest of the document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
- The document requests to "register" the ietf-layer0-types module in the "YANG Module Names" registry [RFC6020] within the "YANG
  Parameters" registry group. Such module already exists as it was created for RFC9093. SHould the draft be updated to ask for it's update instead of registration?

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Request for posting confirmation emailed to previous authors: Aihua Guo , Daniel King , Dieter Beller , Esther Le Rouzic , Haomian Zheng , Italo Busi , Sergio Belotti