Ballot for draft-ietf-ccamp-rfc9093-bis
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
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");
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.
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,
<https://www.rfc-editor.org/rfc/rfc9093>.
6.2. Informative References
Please move 9093 to be listed as Informative.
# 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,
<https://www.rfc-editor.org/rfc/rfc6020>.
[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,
<https://www.rfc-editor.org/rfc/rfc6241>.
# 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
One very easy comment: Normative References: If a draft is being obsoleted, then it can't be normative. Please make RFC9093 Informative.
Thank you to Thomas Fossati for the GENART review.
# É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.