A YANG Data Model for Optical Impairment-aware Topology
draft-ietf-ccamp-optical-impairment-topology-yang-24

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

Thank you for meticulously tracking and addressing all issue. Much appreciated.

The clarifications provided by email and changes made in [1] address all the points raised in my previous ballot [2]. Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-ccamp-optical-impairment-topology-yang-20&url2=draft-ietf-ccamp-optical-impairment-topology-yang-22&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/ccamp/q1PeAMRd3pzg561A8wXJXAVu5Lc/

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

Overall, the clarifications provided by email and changes made in [1] address almost all the points raised in my previous ballot [2]. Thank you.

The only remaining one is this one:

# Many of G-* ITU-T specs listed in the document are normative

Please double check the classification of these.

The new version seems to not implement the following:

"
Authors> We agreed to proceed in this way:

Move the following references to Normative:

G.680
G.807 and G.807 Amd1
G.694.1
G.959.1
G.698.2

See #209
"

[Ballot comment]
Please fix also the following:

# These are listed as normative, while they shouldn't

  [RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
              January 2006, .

  [I-D.ietf-netmod-rfc8407bis]
              Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
              Authors and Reviewers of Documents Containing YANG Data
              Models", Work in Progress, Internet-Draft, draft-ietf-
              netmod-rfc8407bis-28, 5 June 2025,
              .

  [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              .

Please move them to be listed as Informative.

# This one is now unused in -21. Please remove it from the references:

CURRENT:
  [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              .

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-ccamp-optical-impairment-topology-yang-20&url2=draft-ietf-ccamp-optical-impairment-topology-yang-21&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/ccamp/q1PeAMRd3pzg561A8wXJXAVu5Lc/

[Ballot discuss]
I promised that I would complete the review after stopping the last time because of the number of issues. I have added one more DISCUSS to the list, and a few more COMMENTS. With the number of changes requested, and if agreed, it would be good to do another quick LC just to make sure the WG is ok with the changes.

Section 4, paragraph 0
>    file "ietf-optical-impairment-topology.yang"
>    module ietf-optical-impairment-topology {
>      yang-version 1.1;
>      namespace "urn:ietf:params:xml"
>              + ":ns:yang:ietf-optical-impairment-topology";
>      prefix oit;

There are a couple of issues with this module.
- There is no date (or revision) in the name of the file. Please add one.
- The model does not validate for me using either pyang or yanglint. I could be doing something wrong, but here is what I am using. The bin directory has all the latest modules as maintained by IANA.

$ yanglint -p bin/yang-parameters/ ietf-optical-impairment-topology.yang
libyang err : Grouping "l0-types:frequency-range-with-identifier" referenced by a uses statement not found. (Path "/ietf-optical-impairment-topology:{grouping='amplifier-params'}/amplifier/operational/amplifier-element/{uses='l0-types:frequency-range-with-identifier'}".)
YANGLINT[E]: Parsing schema module "ietf-optical-impairment-topology.yang" failed.

$ pyang --ietf -p bin/yang-parameters/ ietf-optical-impairment-topology.yang
ietf-optical-impairment-topology.yang:1281 (at ietf-optical-impairment-topology.yang:132): error: the key "frequency-range-id" does not reference an existing leaf
ietf-optical-impairment-topology.yang:139: error: grouping "frequency-range-with-identifier" not found in module "ietf-layer0-types"


Separately, please list all the RFCs whose modules are imported in the document at the begining of the section, and outise the block so they can be normatively referenced.

Section 4, paragraph 4
>        Editor:  Young Lee
>        Editor:  Haomian Zheng
>        Editor:  Nicola Sambo
>        Editor:  Victor Lopez
>        Editor:  Gabriele Galimberti
>        Editor:  Giovanni Martinelli
>        Editor:  Jean-Luc Auge
>        Editor:  Le Rouzic Esther
>        Editor:  Julien Meuric
>        Editor:  Italo Busi
>        Editor:  Dieter Beller
>        Editor:  Sergio Belotti
>        Editor:  Griseri Enrico
>        Editor:  Gert Grammel ";

How come the document has 5 authors but 14 editors?

Section 4, paragraph 14
>                  case channel-power {
>                    leaf nominal-carrier-power {
>                      type l0-types:power-dbm-or-unknown;
>                      mandatory true;
>                      description
>                        "Reference channel power.";
>                    }
>                  }
>                  case power-spectral-density {
>                    leaf nominal-psd {
>                      type l0-types:psd-or-unknown;
>                      mandatory true;
>                      description
>                        "Reference power spectral density (PSD).";
>                    }
>                  }
>                }

You cannot have both cases of the choice statement be mandatory true, as only one of them is valid at any time. If the idea is that the choice of power-param is mandatory, which you have already set to mandatory true, you do not need to have a mandatory true statement in each case statement.

This setting of mandatory parameters gets even more egregious further below. Please move the mandatory statement out of case and put it under the choice statement.

Section 4, paragraph 34
>      augment "/nw:networks/nw:network/nw:network-types"
>            + "/tet:te-topology" {
>        description
>          "optical-impairment topology augmented";
>        container optical-impairment-topology {
>          presence
>            "Indicates an impairment-aware topology of optical networks";
>          description
>            "Container to identify impairment-aware topology type";
>          reference
>            "RFC8345: A YANG Data Model for Network Topologies.";
>        }
>      }

I want to understand the purpose of having a presence container with no nodes defined in it. If the idea is to enable a particular feature, a simple boolean flag should suffice. See comment below.

Section 4, paragraph 34
>        when './nw:network-types/tet:te-topology'
>          + '/oit:optical-impairment-topology' {
>          description
>            "This augment is only valid for Optical Impairment
>            topology.";
>        }

Having created a presence container, this 'when' statement will always be true, which means anyone implemeting this model will create a optical impairment topology. Where is the when in the 'when' statement?

[Ballot comment]
"Abstract", paragraph 1
>    This document provides a YANG data model for the impairment-aware TE
>    topology in optical networks.

The Shepherd's Report template asks whether the document is "is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? To which the response is "Yes, the WG has been working on it for a long time. This work is ready to be handed off to AD." The fact that the document has been worked upon for several years does not mean it is ready to be handed off to the AD. :-) This is a side note, and no action is expected.

Section 1, paragraph 0
>    In order to provision an optical connection (an optical path) through
>    a wavelength switched optical networks (WSONs) as defined in
>    [RFC9094] or spectrum switched optical networks (SSONs), a
>    combination of path continuity, resource availability, and impairment
>    constraints must be met to determine viable and optimal paths through
>    the network.  The determination of appropriate paths is known as
>    Impairment-Aware Routing and Wavelength Assignment (IA-RWA) [RFC6566]
>    for WSON, while it is known as IA-Routing and Spectrum Assigment (IA-
>    RSA) for SSON.

This is almost an exact copy of the Abstract, except maybe for the references. Those RFC numbers could have been added in the Abstract (without the square brackets), and this paragraph could be removed. Otherwise, please reword to explain the abstract a little more.

Section 1, paragraph 1
>    This document provides a YANG data model for the impairment-aware
>    Traffic Engineering (TE) topology in WSONs and SSONs.  The YANG model
>    described in this document is a WSON/SSON technology-specific Yang
>    model based on the information model developed in [RFC7446] and the
>    two encoding documents [RFC7581] and [RFC7579] that developed
>    protocol independent encodings based on [RFC7446].

Is this a YANG 1.1 or a 1.0 model? Also, please be consistent in the use of YANG (it should be all caps).

Section 1, paragraph 1
>    The intent of this document is to provide a YANG data model, which
>    can be utilized by a Multi-Domain Service Coordinator (MDSC) to
>    collect WSON impairment data from the Provisioning Network
>    Controllers (PNCs) to enable impairment-aware optical path
>    computation according to the ACTN Architecture [RFC8453].  The
>    communication between controllers is done via a NETCONF [RFC8341] or
>    a RESTCONF interface.  [RFC8040].

RFC8341 is not NETCONF. Please correct the reference.

Section 1, paragraph 1
>    It is worth noting that optical data plane interoperability is a
>    complex topic especially in a multi-vendor environment and usually
>    requires joint engineering, which is independent from control plane
>    and management plane capabilities.  The YANG data model defined in
>    this document is providing sufficient information to enable optical
>    impairment-aware path computation.

I am not clear on the purpose of this paragraph. The last sentence is the only useful information, but even that is a repeat of from the Abstract/Introduction. Please remove.

Section 1, paragraph 1
>    This document augments the generic TE topology YANG model defined in
>    [RFC8795] where possible.

... And what happens to the model where it cannot augment the generic TE topology?

Section 1, paragraph 1
>    The optical impairment-aware topology for a WSON/SSON network based
>    on the YANG data model defined in this document is intended to be
>    used for exposing the network topology including optical impairments.
>    Therefore, the topology information that is typically provided by a
>    PNC is assumed to be read-only data, i.e., not configurable (read-
>    write).  This may change when the same optical impairment-aware
>    topology model is used for other use cases than exposing the network
>    topology.  E.g., for a path computation engine, where topological
>    elements could be added in the context of a what-if scenario
>    analysis.  This is outside of the scope of this document.

The sentence "is assumed to be read-only data, i.e., not configurable (read-write) is confusing. Please remove everything after "read-only data".

Section 1, paragraph 1
>    This document defines one YANG module: ietf-optical-impairment-
>    topology (Section 3) according to the new Network Management
>    Datastore Architecture [RFC8342].

Drop the word new in the sentence. There is no "new" NMDA.

Section 2.1, paragraph 1
>    The optical impairment-aware topology YANG model defined in this
>    document is a network model as defined in [RFC8969] and is applicable
>    to devices and network controllers.  The topology model provides
>    read-only network topology status information that is typically used
>    for path computation during service provisioning when a new service
>    is established on the network.
>
>    The DWDM interface YANG model defined in
>    [I-D.ietf-ccamp-dwdm-if-param-yang] is a device model as defined in
>    [RFC8969] (a DWDM interface management model to be precise) and is
>    intended to be used for device configuration.


This section sounded promising as it described the scope of the YANG module. I believe it is key to understanding the model, and I would encourage the authors to explain it further, preferably with a diagram that explains the relationship between the different models in question. For example, it started by saying earlier in the document that "which can be utilized by a Multi-Domain Service Coordinator (MDSC) to collect WSON impairment data from the Provisioning Network Controllers (PNCs) to enable impairment-aware optical path computation according to the ACTN Architecture [RFC8453]." That sounds like a network model. But it confused me by saying that it is applicable to devices AND network controllers. What is not clear is how it is applicable. Applicable, as in implemented for a device and a network controller? Applicable because the network model collects the data from the devices? If the latter, the sentence above needs to be clear.

Section 3, paragraph 0
>    module: ietf-optical-impairment-topology

This (rather complete) tree diagram should be moved into the Appendix, and the section should be replaced with relevant snippets that tie to all the technology details provided above. Otherwise, a big tree diagram is useless in helping anyone understand the relationship between the technology and the design of the module.

Section 4, paragraph 13
>        container amplifier {
>          description
>            "Amplifier type, operational parameters are described.";
>          leaf type-variety {
>            type string;
>            mandatory true;
>            description
>              "String identifier of amplifier type referencing
>              a specification in a separate equipment catalog";
>          }

An "operational parameter" in YANG is a read-only variable, which this does not seem to be. Can this be reworded or removed?

Section 4, paragraph 16
>          leaf total-loss {
>            type l0-types:power-loss-or-unknown;
>            description
>              "The measured total loss of the fiber, which includes
>              all possible losses: fiber loss and conn-in and conn-out
>              losses.
>
>              This attribute is not present when the total loss cannot
>              be measured.";
>          }

If this is a measured value, then it is not configurable, in which case it should be 'config false'. The same seems to be true for nodes below. Suggest that authors examine it for read-only capability.

Also, what does it mean for the attribute to be "not present"? How do you make sure the node is "not present"?

Section 4, paragraph 15
>          leaf pmd {
>            type l0-types:decimal-2-or-unknown;
>            units "ps";
>            description
>              "PMD of the fiber";
>          }


Although PMD is expanded somewhere in the document and later in this module, please note that the YANG module is detached from the document. As such, for an implementer, it would help to have a description where acronyms are expanded (again, for the first time it is used in the module), and there is an explanation for the expanded acronym such that it is self-sufficient for the node. That is specifically true for the next few nodes, where the node description is just the same as the name of the leaf.

Section 4, paragraph 15
>        leaf roadm-cd {
>          type l0-types:decimal-5-or-unknown;
>          units "ps/nm";
>          description
>            "Chromatic Dispersion (CD)";
>        }

How about a more descriptive description statement. Something along the lines of (btw, this was found searching on Wikipedia):

"Chromatic dispersion is the phenomenon where different wavelengths of light travel at different speeds in a medium, causing a pulse of light to spread out over time. This effect is significant in optical fibers, where it can impact the quality of data transmission."

Section 4, paragraph 14
>        leaf roadm-pdl {
>          type l0-types:power-loss-or-unknown;
>          description
>            "Polarization Dependent Loss (PDL)";
>        }

And something like this for this node:

"Polarization-dependent loss (PDL) refers to the variation in insertion loss or gain of an optical component based on the polarization state of light passing through it. It is an important factor in telecommunications, as it can affect the performance and efficiency of optical systems."

Section 4, paragraph 14
>      grouping roadm-express-path {
>        description
>          "The optical impairments of a ROADM express path.";
>        uses roadm-common-path;
>      } // grouping roadm-express-path

If the only grouping this grouping includes is roadm-common-path, why do you need another grouping for it?

Section 4, paragraph 26
>      grouping roadm-add-path {
>        description
>          "The optical impairments of a ROADM add path.";
>        uses roadm-common-path {
>          refine "roadm-inband-crosstalk" {
>            description
>              "In-band crosstalk, or coherent crosstalk,
>              can occur in components that can have multiple same
>              wavelength inputs,with the inputs either
>              routed to different output ports,
>              or all but one blocked.
>
>              In the case of add path it is the total
>              of the add block + egress WSS crosstalk contributions.";
>          }
>          refine "roadm-maxloss" {
>            description
>              "This is the maximum expected add path loss from
>              the add/drop port input to the ROADM egress,
>              assuming no additional add path loss is added.
>
>              This is used to establish the minimum required
>              transponder output power required
>              to hit the ROADM egress target power
>              levels and preventing
>              to hit the WSS attenuation limits.
>
>              If the add path contains an internal amplifier
>              this loss value MUST be based
>              on worst case expected amplifier gain due to
>              ripple or gain uncertainty";
>          }
>        }
>        leaf roadm-pmax {
>          type l0-types:power-dbm-or-unknown;
>          description
>            "This is the maximum (per carrier) power level
>            permitted at the add block input ports,
>            that can be handled by the ROADM node.
>
>            This can reflect either add amplifier power
>            constraints or WSS adjustment limits.
>            Higher power transponders would need to have
>            their launch power reduced
>            to this value or lower";
>        }
>        leaf roadm-osnr {
>          type l0-types:snr-or-unknown;
>          description
>            "Optical Signal-to-Noise Ratio (OSNR).
>
>            If the add path contains the ability to adjust the
>            carrier power levels into an add path amplifier
>            (if present) to a target value,
>            this reflects the OSNR contribution of the
>            add amplifier assuming this target value is obtained.
>
>            The worst case OSNR based on the input power and
>            NF calculation method, and this value, MUST be used
>            (if both are defined).";
>        }
>        leaf roadm-noise-figure {
>          type l0-types:decimal-5-or-unknown;
>          units "dB";
>          description
>            "Noise Figure. If the add path contains an amplifier,
>            this is the noise figure of that amplifier inferred
>            to the add port.
>            This permits add path OSNR calculation based
>            on the input power levels to the add block
>            without knowing the ROADM path losses to
>            the add amplifier.";
>        }
>      } // grouping roadm-add-path
>
>      grouping roadm-drop-path {
>        description
>          "The optical impairments of a ROADM drop path";
>        uses roadm-common-path {
>          refine "roadm-inband-crosstalk" {
>            description
>              "In-band crosstalk, or coherent crosstalk, can occur in
>              components that can have multiple same wavelength
>              inputs,with the inputs either routed to different
>              output ports,or all but one blocked.
>
>              In the case of drop path it is the total
>              of the ingress
>              to drop e.g. WSS and drop block crosstalk
>              contributions.";
>          }
>          refine "roadm-maxloss" {
>            description
>              "The net loss from the ROADM input,to the output
>              of the drop block.
>              If this ROADM ingress-to-drop path includes an amplifier,
>              the amplifier gain reduces the net loss.
>              This is before any additional drop path attenuation
>              that may be required
>              due to drop amplifier power constraints.
>              The max value correspond to worst case expected loss,
>              including amplifier gain ripple or uncertainty.
>              It is the maximum output power of the drop
>              amplifier.";
>          }
>        }
>        leaf roadm-minloss {
>          type l0-types:power-loss-or-unknown;
>          description
>            "The net loss from the ROADM input, to the
>            output of the drop block.
>            If this ROADM ingress-to-drop path includes
>            an amplifier,the amplifier gain reduces the net loss.
>            This is before any additional drop path attenuation
>            that may be required due to drop amplifier power
>            constraints.
>            The min value correspond to best case expected loss,
>            including amplifier gain ripple or uncertainty.";
>        }
>        leaf roadm-typloss {
>          type l0-types:power-loss-or-unknown;
>          description
>            "The net loss from the ROADM input,
>            to the output of the drop block.
>            If this ROADM ingress-to-drop path
>            includes an amplifier,
>            the amplifier gain reduces the net loss.
>            This is before any additional drop path
>            attenuation
>            that may be required due to drop amplifier
>            power constraints.
>            The typ value correspond to typical case
>            expected loss.";
>        }
>        leaf roadm-pmin {
>          type l0-types:power-dbm-or-unknown;
>          description
>            "If the drop path has additional loss that is added, for
>            example, to hit target power levels into a drop path
>            amplifier, or simply, to reduce the power of a strong
>            carrier (due to ripple, for example), then the use of the
>            ROADM input power levels and the above drop losses is
>            not appropriate.
>
>            This parameter corresponds to the minimum value of the Drop
>            Channel output power range, as defined in table 8-6 of
>            ITU-T G.680.";
>          reference
>            "ITU-T G.680 v1.0 (07/2007): Physical transfer functions of
>                      optical network elements, table 8-6";
>        }
>        leaf roadm-pmax {
>          type l0-types:power-dbm-or-unknown;
>          description
>            "If the drop path has additional loss that is added, for
>            example, to hit target power levels into a drop path
>            amplifier, or simply ,to reduce the power of a strong
>            carrier (due to ripple, for example), then the use of the
>            ROADM input power levels and the above drop losses is
>            not appropriate.
>
>            This parameter corresponds to the maximum value of the Drop
>            Channel output power range, as defined in table 8-6 of
>            ITU-T G.680.";
>          reference
>            "ITU-T G.680 v1.0 (07/2007): Physical transfer functions of
>                      optical network elements, table 8-6";
>        }
>        leaf roadm-ptyp {
>          type l0-types:power-dbm-or-unknown;
>          description
>            "If the drop path has additional loss that is added,
>            for example, to hit target power levels into a
>            drop path amplifier,or simply,to reduce the
>            power of a strong carrier(due to ripple,for example),
>            then the use of the ROADM input power levels and
>            the above drop losses is not appropriate.
>            This parameter corresponds to the typical case
>            per carrier power levels expected
>            at the output of the drop block.";
>        }
>        leaf roadm-osnr {
>          type l0-types:snr-or-unknown;
>          description
>            "Optical Signal-to-Noise Ratio (OSNR).
>
>            Expected OSNR contribution of the drop path
>            amplifier(if present)
>            for the case of additional drop path loss
>            (before this amplifier)
>            in order to hit a target power level (per carrier).
>
>            If both, the OSNR based on the ROADM
>            input power level
>            (Pcarrier =
>            Pref+10Log(carrier-baudrate/ref-baud) + delta-power)
>            and the input inferred NF(NF.drop),
>            and this OSNR value, are defined,
>            the minimum value between these two MUST be used";
>        }
>        leaf roadm-noise-figure {
>          type l0-types:decimal-5-or-unknown;
>          units "dB";
>          description
>            "Drop path Noise Figure.
>            If the drop path contains an amplifier,
>            this is the noise figure
>            of that amplifier, inferred to the
>            ROADM ingress port.
>            This permits to determine
>            amplifier OSNR contribution
>            without having to specify the
>            ROADM node's losses to that amplifier.
>            This applies for the case of no
>            additional drop path loss,
>            before the amplifier, in order to reduce the power
>            of the carriers to a target value";
>        }
>      } // grouping roadm-drop-path

A quick look at these two groupings did not yield a difference for me, except for the name. Maybe I missed something, or it is too subtle a change, but if they indeed are the same, can they be collapsed?

Section 4, paragraph 30
>            type union {
>              type l0-types:frequency-thz;
>              type l0-types:unknown-value;
>            }


Could this also be a typedef like other nodes?

Section 4, paragraph 32
>          This grouping is not intended to be reused outside of this
>          module.";

If this grouping is to be used in this module only, and there is only one use of it, why not inline it with where it is being used?

Section 4, paragraph 33
>            leaf oms-element-uid {
>              type union {
>                type string;
>                type l0-types:unknown-value;
>              }
>              description
>                "Unique id of the element.";
>            }

How can an id be unique if one of the possible values is 'unknown'?

Section 5, paragraph 0
>    The YANG module specified in this document defines a schema for data
>    that is designed to be accessed via network management protocols such
>    as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
>    is the secure transport layer, and the mandatory-to-implement secure
>    transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
>    is HTTPS, and the mandatory-to-implement secure transport is TLS
>    [RFC8446].

Please update this template as described in rfc8407bis.

-------------------------------------------------------------------------------
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 2.3.4, paragraph 1
> n amplifiers are widely used. Raman amplifiers have become attractive due to
>                              ^^^^^^^^^^^^^^^^
The genitive ('s) may be missing.

Section 2.3.4, paragraph 2
> ly more expensive than EDFAs. Raman amplifiers are distributed amplifiers whe
>                              ^^^^^^^^^^^^^^^^
The genitive ('s) may be missing.

Section 2.4, paragraph 3
> on the egress side, which allows to control the optical power of the WDM out
>                                  ^^^^^^^^^^
Did you mean "controlling"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 2.4, paragraph 12
> mic Gain Equalizer (DGE) is an optical equipment that is capable of adjusting
>                            ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"optical equipment".

Section 2.4, paragraph 12
> adjusting the optical power on a per channel basis in order to compensate the
>                                  ^^^^^^^^^^^
In this context, "per-channel" forms an adjective and is spelled with a hyphen.

Section 2.4, paragraph 13
> sponders A transponder is an optical equipment that sends and receives the o
>                          ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"optical equipment".

Section 2.6.1, paragraph 4
> dence. This should, however, only be an done in exceptional cases and should
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.6.2, paragraph 3
> t Modes The explicit mode allows to encode, explicitly, any subset of parame
>                                  ^^^^^^^^^
Did you mean "encoding"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 2.6.2, paragraph 3
> ers e.g., FEC type, Modulation type, etc, to enable a controller entity to ch
>                                      ^^^
A period is needed after the abbreviation "etc.".

Section 2.6.4, paragraph 16
> n and each transceiver is operated in an uni-directional mode. Implementation
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.7, paragraph 3
> elects the wavelength that is of interest by deflecting it from the original
>                                  ^^^^^^^^^^^
The usual collocation for "interest" is "in", not "by".

Section 2.10.3, paragraph 5
> protection architecture requires dedicated photonic protection functions in
>                                  ^^^^^^^^^
The double modal "requires dedicated" is nonstandard (only accepted in certain
dialects). Consider "to be dedicated".

Section 2.11.1.2, paragraph 7
> case the optical impairments of the worse of the two underlying TE-links shal
>                                    ^^^^^
"Worst" seems more likely than "worse" in this context.

Section 2.11.2, paragraph 4
> d on the optical impairments of the worse of the two underlying physical OMS
>                                    ^^^^^
"Worst" seems more likely than "worse" in this context.

Section 2.11.2.2, paragraph 22
> -range-with-identifier" referenced by a uses statement not found. (Path "/iet
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.11.2.2, paragraph 22
> separate equipment catalog. This attributes applies only when the type-variet
>                                  ^^^^^^^^^^
Consider using the singular form after the singular determiner "This".

Section 2.11.2.2, paragraph 22
> ; mandatory true; description "It represent total output power measured in th
>                                  ^^^^^^^^^
After "It", use the third-person verb form "represents".

Section 2.11.2.2, paragraph 22
> amplifier inferred to the add port. This permits add path OSNR calculation b
>                                    ^^^^
Did you mean "these"?

Section 2.11.2.2, paragraph 22
> power constraints. The max value correspond to worst case expected loss, inc
>                                  ^^^^^^^^^^
The verb form "correspond" does not seem to match the subject "value".

Section 2.11.2.2, paragraph 22
> raints. The max value correspond to worst case expected loss, including ampli
>                                    ^^^^^
A determiner may be missing.

Section 2.11.2.2, paragraph 28
> o reduce the power of a strong carrier(due to ripple,for example), then the u
>                                      ^
It appears that a white space is missing.

Section 2.11.2.2, paragraph 30
> ontribution of the drop path amplifier(if present) for the case of additional
>                                      ^
It appears that a white space is missing.

Section 2.11.2.2, paragraph 49
> ent. It could be structured e.g., as an URI or as an UUID."; } uses otsi-gro
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.11.2.2, paragraph 49
>  be structured e.g., as an URI or as an UUID."; } uses otsi-group; } // list
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.11.2.2, paragraph 50
> iption "The textual description of the the set of optical impairments related
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 2.11.2.2, paragraph 50
> escription "The transponder can be configure to be used either in an Optical
>                                ^^^^^^^^^^^^
There may an error in the verb form "be configure".

Section 2.11.2.2, paragraph 56
>  a group of transponder in which an a an electrical connectivity is either i
>                                    ^^^^
Two determiners in a row. Choose either "a" or "an".

Section 2.11.2.2, paragraph 75
> tion "The list of transceivers having a LLC different from the default LLC.";
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.11.2.2, paragraph 75
> "; } description "The reference to the the transceiver of this LLCL entry.";
>                                    ^^^^^^^
Possible typo: you repeated a word.

[Ballot discuss]
Section 4, paragraph 0
>    file "ietf-optical-impairment-topology.yang"
>    module ietf-optical-impairment-topology {
>      yang-version 1.1;
>      namespace "urn:ietf:params:xml"
>              + ":ns:yang:ietf-optical-impairment-topology";
>      prefix oit;

There are a couple of issues with this module.
- There is no date (or revision) in the name of the file. Please add one.
- The model does not validate for me using either pyang or yanglint. I could be doing something wrong, but here is what I am using. The bin directory has all the latest modules as maintained by IANA.

$ yanglint -p bin/yang-parameters/ ietf-optical-impairment-topology.yang
libyang err : Grouping "l0-types:frequency-range-with-identifier" referenced by a uses statement not found. (Path "/ietf-optical-impairment-topology:{grouping='amplifier-params'}/amplifier/operational/amplifier-element/{uses='l0-types:frequency-range-with-identifier'}".)
YANGLINT[E]: Parsing schema module "ietf-optical-impairment-topology.yang" failed.

$ pyang --ietf -p bin/yang-parameters/ ietf-optical-impairment-topology.yang
ietf-optical-impairment-topology.yang:1281 (at ietf-optical-impairment-topology.yang:132): error: the key "frequency-range-id" does not reference an existing leaf
ietf-optical-impairment-topology.yang:139: error: grouping "frequency-range-with-identifier" not found in module "ietf-layer0-types"


Separately, please list all the RFCs whose modules are imported in the document at the begining of the section, and outise the block so they can be normatively referenced.

Section 4, paragraph 4
>        Editor:  Young Lee
>        Editor:  Haomian Zheng
>        Editor:  Nicola Sambo
>        Editor:  Victor Lopez
>        Editor:  Gabriele Galimberti
>        Editor:  Giovanni Martinelli
>        Editor:  Jean-Luc Auge
>        Editor:  Le Rouzic Esther
>        Editor:  Julien Meuric
>        Editor:  Italo Busi
>        Editor:  Dieter Beller
>        Editor:  Sergio Belotti
>        Editor:  Griseri Enrico
>        Editor:  Gert Grammel ";

How come the document has 5 authors but 14 editors?

Section 4, paragraph 14
>                  case channel-power {
>                    leaf nominal-carrier-power {
>                      type l0-types:power-dbm-or-unknown;
>                      mandatory true;
>                      description
>                        "Reference channel power.";
>                    }
>                  }
>                  case power-spectral-density {
>                    leaf nominal-psd {
>                      type l0-types:psd-or-unknown;
>                      mandatory true;
>                      description
>                        "Reference power spectral density (PSD).";
>                    }
>                  }
>                }

You cannot have both cases of the choice statement be mandatory true, as only one of them is valid at any time. If the idea is that the choice of power-param is mandatory, which you have already set to mandatory true, you do not need to have a mandatory true statement in each case statement.

This setting of mandatory parameters gets even more egregious further below. Please articulate which parameters are actually mandatory.

[Ballot comment]
"Abstract", paragraph 1
>    This document provides a YANG data model for the impairment-aware TE
>    topology in optical networks.

The Shepherd's Report template asks whether the document is "is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? To which the response is "Yes, the WG has been working on it for a long time. This work is ready to be handed off to AD." The fact that the document has been worked upon for several years does not mean it is ready to be handed off to the AD. :-) This is a side note, and no action is expected.

Section 1, paragraph 0
>    In order to provision an optical connection (an optical path) through
>    a wavelength switched optical networks (WSONs) as defined in
>    [RFC9094] or spectrum switched optical networks (SSONs), a
>    combination of path continuity, resource availability, and impairment
>    constraints must be met to determine viable and optimal paths through
>    the network.  The determination of appropriate paths is known as
>    Impairment-Aware Routing and Wavelength Assignment (IA-RWA) [RFC6566]
>    for WSON, while it is known as IA-Routing and Spectrum Assigment (IA-
>    RSA) for SSON.

This is almost an exact copy of the Abstract, except maybe for the references. Those RFC numbers could have been added in the Abstract (without the square brackets), and this paragraph could be removed. Otherwise, please reword to explain the abstract a little more.

Section 1, paragraph 1
>    This document provides a YANG data model for the impairment-aware
>    Traffic Engineering (TE) topology in WSONs and SSONs.  The YANG model
>    described in this document is a WSON/SSON technology-specific Yang
>    model based on the information model developed in [RFC7446] and the
>    two encoding documents [RFC7581] and [RFC7579] that developed
>    protocol independent encodings based on [RFC7446].

Is this a YANG 1.1 or a 1.0 model? Also, please be consistent in the use of YANG (it should be all caps).

Section 1, paragraph 1
>    The intent of this document is to provide a YANG data model, which
>    can be utilized by a Multi-Domain Service Coordinator (MDSC) to
>    collect WSON impairment data from the Provisioning Network
>    Controllers (PNCs) to enable impairment-aware optical path
>    computation according to the ACTN Architecture [RFC8453].  The
>    communication between controllers is done via a NETCONF [RFC8341] or
>    a RESTCONF interface.  [RFC8040].

RFC8341 is not NETCONF. Please correct the reference.

Section 1, paragraph 1
>    It is worth noting that optical data plane interoperability is a
>    complex topic especially in a multi-vendor environment and usually
>    requires joint engineering, which is independent from control plane
>    and management plane capabilities.  The YANG data model defined in
>    this document is providing sufficient information to enable optical
>    impairment-aware path computation.

I am not clear on the purpose of this paragraph. The last sentence is the only useful information, but even that is a repeat of from the Abstract/Introduction. Please remove.

Section 1, paragraph 1
>    This document augments the generic TE topology YANG model defined in
>    [RFC8795] where possible.

... And what happens to the model where it cannot augment the generic TE topology?

Section 1, paragraph 1
>    The optical impairment-aware topology for a WSON/SSON network based
>    on the YANG data model defined in this document is intended to be
>    used for exposing the network topology including optical impairments.
>    Therefore, the topology information that is typically provided by a
>    PNC is assumed to be read-only data, i.e., not configurable (read-
>    write).  This may change when the same optical impairment-aware
>    topology model is used for other use cases than exposing the network
>    topology.  E.g., for a path computation engine, where topological
>    elements could be added in the context of a what-if scenario
>    analysis.  This is outside of the scope of this document.

The sentence "is assumed to be read-only data, i.e., not configurable (read-write) is confusing. Please remove everything after "read-only data".

Section 1, paragraph 1
>    This document defines one YANG module: ietf-optical-impairment-
>    topology (Section 3) according to the new Network Management
>    Datastore Architecture [RFC8342].

Drop the word new in the sentence. There is no "new" NMDA.

Section 2.1, paragraph 1
>    The optical impairment-aware topology YANG model defined in this
>    document is a network model as defined in [RFC8969] and is applicable
>    to devices and network controllers.  The topology model provides
>    read-only network topology status information that is typically used
>    for path computation during service provisioning when a new service
>    is established on the network.
>
>    The DWDM interface YANG model defined in
>    [I-D.ietf-ccamp-dwdm-if-param-yang] is a device model as defined in
>    [RFC8969] (a DWDM interface management model to be precise) and is
>    intended to be used for device configuration.


This section sounded promising as it described the scope of the YANG module. I believe it is key to understanding the model, and I would encourage the authors to explain it further, preferably with a diagram that explains the relationship between the different models in question. For example, it started by saying earlier in the document that "which can be utilized by a Multi-Domain Service Coordinator (MDSC) to collect WSON impairment data from the Provisioning Network Controllers (PNCs) to enable impairment-aware optical path computation according to the ACTN Architecture [RFC8453]." That sounds like a network model. But it confused me by saying that it is applicable to devices AND network controllers. What is not clear is how it is applicable. Applicable, as in implemented for a device and a network controller? Applicable because the network model collects the data from the devices? If the latter, the sentence above needs to be clear.

Section 3, paragraph 0
>    module: ietf-optical-impairment-topology

This (rather complete) tree diagram should be moved into the Appendix, and the section should be replaced with relevant snippets that tie to all the technology details provided above. Otherwise, a big tree diagram is useless in helping anyone understand the relationship between the technology and the design of the module.

Section 4, paragraph 13
>        container amplifier {
>          description
>            "Amplifier type, operational parameters are described.";
>          leaf type-variety {
>            type string;
>            mandatory true;
>            description
>              "String identifier of amplifier type referencing
>              a specification in a separate equipment catalog";
>          }

An "operational parameter" in YANG is a read-only variable, which this does not seem to be. Can this be reworded or removed?

Section 4, paragraph 16
>          leaf total-loss {
>            type l0-types:power-loss-or-unknown;
>            description
>              "The measured total loss of the fiber, which includes
>              all possible losses: fiber loss and conn-in and conn-out
>              losses.
>
>              This attribute is not present when the total loss cannot
>              be measured.";
>          }

If this is a measured value, then it is not configurable, in which case it should be 'config false'. The same seems to be true for nodes below. Suggest authors examine it for read-only capability.

Also, what does it mean for the attribute to be "not present"? How do you make sure the node is "not present"?

At this point, I stopped my review as the model has way too many issues. I would suggest that this document should undergo another YANG Doctors review before it is brought back for IESG review.

Section 5, paragraph 0
>    The YANG module specified in this document defines a schema for data
>    that is designed to be accessed via network management protocols such
>    as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
>    is the secure transport layer, and the mandatory-to-implement secure
>    transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
>    is HTTPS, and the mandatory-to-implement secure transport is TLS
>    [RFC8446].

Please update this template as described in rfc8407bis.

-------------------------------------------------------------------------------
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 2.3.4, paragraph 1
> n amplifiers are widely used. Raman amplifiers have become attractive due to
>                              ^^^^^^^^^^^^^^^^
The genitive ('s) may be missing.

Section 2.3.4, paragraph 2
> ly more expensive than EDFAs. Raman amplifiers are distributed amplifiers whe
>                              ^^^^^^^^^^^^^^^^
The genitive ('s) may be missing.

Section 2.4, paragraph 3
> on the egress side, which allows to control the optical power of the WDM out
>                                  ^^^^^^^^^^
Did you mean "controlling"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 2.4, paragraph 12
> mic Gain Equalizer (DGE) is an optical equipment that is capable of adjusting
>                            ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"optical equipment".

Section 2.4, paragraph 12
> adjusting the optical power on a per channel basis in order to compensate the
>                                  ^^^^^^^^^^^
In this context, "per-channel" forms an adjective and is spelled with a hyphen.

Section 2.4, paragraph 13
> sponders A transponder is an optical equipment that sends and receives the o
>                          ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"optical equipment".

Section 2.6.1, paragraph 4
> dence. This should, however, only be an done in exceptional cases and should
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.6.2, paragraph 3
> t Modes The explicit mode allows to encode, explicitly, any subset of parame
>                                  ^^^^^^^^^
Did you mean "encoding"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 2.6.2, paragraph 3
> ers e.g., FEC type, Modulation type, etc, to enable a controller entity to ch
>                                      ^^^
A period is needed after the abbreviation "etc.".

Section 2.6.4, paragraph 16
> n and each transceiver is operated in an uni-directional mode. Implementation
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.7, paragraph 3
> elects the wavelength that is of interest by deflecting it from the original
>                                  ^^^^^^^^^^^
The usual collocation for "interest" is "in", not "by".

Section 2.10.3, paragraph 5
> protection architecture requires dedicated photonic protection functions in
>                                  ^^^^^^^^^
The double modal "requires dedicated" is nonstandard (only accepted in certain
dialects). Consider "to be dedicated".

Section 2.11.1.2, paragraph 7
> case the optical impairments of the worse of the two underlying TE-links shal
>                                    ^^^^^
"Worst" seems more likely than "worse" in this context.

Section 2.11.2, paragraph 4
> d on the optical impairments of the worse of the two underlying physical OMS
>                                    ^^^^^
"Worst" seems more likely than "worse" in this context.

Section 2.11.2.2, paragraph 22
> -range-with-identifier" referenced by a uses statement not found. (Path "/iet
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.11.2.2, paragraph 22
> separate equipment catalog. This attributes applies only when the type-variet
>                                  ^^^^^^^^^^
Consider using the singular form after the singular determiner "This".

Section 2.11.2.2, paragraph 22
> ; mandatory true; description "It represent total output power measured in th
>                                  ^^^^^^^^^
After "It", use the third-person verb form "represents".

Section 2.11.2.2, paragraph 22
> amplifier inferred to the add port. This permits add path OSNR calculation b
>                                    ^^^^
Did you mean "these"?

Section 2.11.2.2, paragraph 22
> power constraints. The max value correspond to worst case expected loss, inc
>                                  ^^^^^^^^^^
The verb form "correspond" does not seem to match the subject "value".

Section 2.11.2.2, paragraph 22
> raints. The max value correspond to worst case expected loss, including ampli
>                                    ^^^^^
A determiner may be missing.

Section 2.11.2.2, paragraph 28
> o reduce the power of a strong carrier(due to ripple,for example), then the u
>                                      ^
It appears that a white space is missing.

Section 2.11.2.2, paragraph 30
> ontribution of the drop path amplifier(if present) for the case of additional
>                                      ^
It appears that a white space is missing.

Section 2.11.2.2, paragraph 49
> ent. It could be structured e.g., as an URI or as an UUID."; } uses otsi-gro
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.11.2.2, paragraph 49
>  be structured e.g., as an URI or as an UUID."; } uses otsi-group; } // list
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 2.11.2.2, paragraph 50
> iption "The textual description of the the set of optical impairments related
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 2.11.2.2, paragraph 50
> escription "The transponder can be configure to be used either in an Optical
>                                ^^^^^^^^^^^^
There may an error in the verb form "be configure".

Section 2.11.2.2, paragraph 56
>  a group of transponder in which an a an electrical connectivity is either i
>                                    ^^^^
Two determiners in a row. Choose either "a" or "an".

Section 2.11.2.2, paragraph 75
> tion "The list of transceivers having a LLC different from the default LLC.";
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.11.2.2, paragraph 75
> "; } description "The reference to the the transceiver of this LLCL entry.";
>                                    ^^^^^^^
Possible typo: you repeated a word.

[Ballot comment]
This is not my area of expertise, so feel free to chalk any of these up to my unfamiliarity with the area.

Thanks for a good introduction and terminology section with lots of references to where you're getting relevant terms. There are a few acronyms it would be nice to expand on first use and possibly reference specifically from Terminology if appropriate -- "TE topology" in the abstract, plus "DWDM", "OMS", and "OTS" in the main document.

Throughout, consider whether "optical impairment-aware" should be "optical-impairment-aware" so it's clear that "optical" describes the impairment, rather than the thing which is impairment-aware.

In 2.1, it's not clear to me how the DWDM model (an informative reference!) is relevant and/or non-normative. Should this be something like "The model in this document does not provide device configuration capabilities. Where those capabilities are needed, a device model as defined in RFC8969 can be used; [I-D....] defines such a model for DWDM interfaces."

Please verify the use of "model" versus "module" throughout.

===NITS FOLLOW===

All in Section 1:

- "Yang" => "YANG" (Also in Section 4)
- "model, which" => "model that"
- "is providing" => "provides"

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

Thank you for the effort put into this specification. Special thanks for the “tutorial” provided in Section 2. That's really helpful.

Please find below some DISCUSS/COMMENTs. Most are easy to fix. Let me know if ant clarification is needed.

# Compact encoding & large scale topologies

The module includes provisions for templating. However, there is still room to factorize among several nodes for the sake of compact large scale topologies. For example, the example data instance provided in the document has the following:

CURRENT:
                "roadm-path-impairments-set": [
                    {
                      "roadm-path-impairments-set-id": "1",
                      "description": "Add path impairments from TTP 1 \
  \or TTP 2 to any LTP",

                      "roadm-add-path": [
                        {
                          "frequency-range-id": 0,
                          "frequency-range": {
                              "lower-frequency": "191.3",
                              "upper-frequency": "196.1"
                          }
                        }
                      ]
                    },
                    {
                      "roadm-path-impairments-set-id": "2",
                        "description": "Add path impairments from TTP 3\
  \ or TTP 4 to LTP1 or LTP3, thorugh AD1",

                      "roadm-add-path": [
                        {
                          "frequency-range-id": 0,
                            "frequency-range": {
                              "lower-frequency": "191.3",
                              "upper-frequency": "196.1"
                            }
                        }
                      ]
                    },
                    {
                      "roadm-path-impairments-set-id": "3",
                      "description": "Add path impairments from TTP 3 \
  \or TTP 4 to LTP1 or LTP2, thorugh AD2",

                      "roadm-add-path": [
                        {
                          "frequency-range-id": 0,
                          "frequency-range": {
                              "lower-frequency": "191.3",
                              "upper-frequency": "196.1"
                          }
                        }
                      ]
                    }
                ]
            }

Did you consider how to factorize such case and similar (by defining the redundant data nodes once and then refer to it as appropriate)?

# Reusable template reference

The module points to templates in many places, while it is cleaner to define a reference typedef for reference purpose; including in future augmentations.

                  type leafref {
                    path "../../../../../../../../oit:templates"
                        + "/oit:explicit-transceiver-modes"
                        + "/oit:explicit-transceiver-mode"
                        + "/oit:explicit-transceiver-mode-id";
                  }

# Security Template

Please update the document to follow the template https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-security-considerations-sect

# Folding

CURRENT:
  Line-folding as defined in [RFC8792] has been used for the JSON code
  example below.

However, RFC8792 says the following:

==
  Text content that has been folded as specified by this strategy MUST
  adhere to the following structure.

7.1.1.  Header

  The header is two lines long.

  The first line is the following 36-character string; this string MAY
  be surrounded by any number of printable characters.  This first line
  cannot itself be folded.

  NOTE: '\' line wrapping per RFC 8792

  The second line is an empty line, containing only the end-of-line
  character sequence.  This line provides visual separation for
  readability.
=

Please fix all your uses on the document to comply with that MUST.

Also, folding is used for the full tree but without including the folding convention. Please fix that as well.

# Broken Examples

Thanks for providing the appendices with the examples. However, these examples seem not to conform to the parent modules. For example, I do see many places where incorrect types are used.

For example, you have:

    "ietf-network:networks": {
      "network": [
        {
          "network-id": "WDM-Network-1",

While network-id is defined as follows in RFC 8345:

    typedef network-id {
      type inet:uri;
      description
        "Identifier for a network.  The precise structure of the
          network-id will be up to the implementation.  The identifier
          SHOULD be chosen such that the same network will always be
          identified through the same identifier, even if the data model
          is instantiated in separate datastores.  An implementation MAY
          choose to capture semantics in the identifier -- for example,
          to indicate the type of network.";
    }

NEW:

    "ietf-network:networks": {
      "network": [
        {
          "network-id": "example:WDM-Network-1",


The same issue applies for node-id such as in:

CURRENT:
          "node": [
            {
              "node-id": "WDM-TE-Node-1",

Idem with tp-id such as in:

CURRENT:
                {
                  "tp-id": "2",

or link-id, source-node, source-tp, e.g.,

CURRENT:
          "ietf-network-topology:link": [
            {
              "link-id": "Add-Drop-Link-1-Forward",
              "source": {
                "source-node": "WDM-TE-Node-1",
                "source-tp": "1"
              },


Etc.

Please validate these examples using tools such yangson and yanglint.

# Many of G-* ITU-T specs listed in the document are normative

Please double check the classification of these.

[Ballot comment]
# YANG Model, YANG Data Model, and YANG Module

The use of “model” vs “module” through the document should be checked to be compliant with the guidance provided in
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-yang-data-model-vs-yang-mod

# ACTN is an example architecture

The mention of ACTN architecture in the introduction smells like if the module can assumes ACTN, while this isn’t the case. It would move the ACTN mention and list as an example in Section 2.

# NMDA

CURRENT:
  This document defines one YANG module: ietf-optical-impairment-
  topology (Section 3) according to the new Network Management
  Datastore Architecture [RFC8342].

Please note the new guidance in RFC8407bis is to mention it when there is major deviations.

# (Unused) Terminology

Please check that all terms listed in Section 1.1 are used in the document. For example, I don’t see the following used.

CURRENT:
  The following terms are defined in [RFC6241] and are not redefined
  here:

  *  configuration data

  *  state data

# Consistent Notations

CURRENT:
  BA (WDM-node 1) is the egress Amplifier and PA (WDM-node 2) is the
  ingress amplifier for the OMS Media Channel Group (MCG) in the
  direction from left to right in Figure 1.

“WDM-node 1”/” WDM-node 2” does not match the nodes cited in the Figure. Please fix that.

# Long tree diagram

The long tree should be moved to an appendix per the guidance in 8407bis.

# Lack of Narrative text and tree snippets to walk through the model

# File name

CURRENT: file "ietf-optical-impairment-topology.yang"

Please update to follow this guidance:

  The "" tag MUST be followed by a string identifying the
  file name specified in Section 5.2 of [RFC7950].  The name string
  form that includes the revision date SHOULD be used.  The revision
  date MUST match the date used in the most recent revision of the
  module.

# String type

The module uses string as type for nodes I expected that some values are already defined. For example:

CURRENT:
        leaf type-variety {
          type string;
          mandatory true;
          description
            "Fiber type";
        }

Any reason why this type is used rather than a structured types (identities, for example)?

# Meaningful descriptions

The module includes many description clauses that are not meaningful. Please consider elaborating this. Example of such uses is:

CURRENT:
        leaf conn-in {
          type l0-types:power-loss-or-unknown;
          description
            "connector-in";

# Do we really need this grouping? Why not simply use roadm-common-path?

CURRENT:
    grouping roadm-express-path {
      description
        "The optical impairments of a ROADM express path.";
      uses roadm-common-path;
    } // grouping roadm-express-path

# Uppercase Identifiers

Upper case is used for several identifiers in the module, including in an inconsistent manner. Please update as appropriate to comply with

  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.

# Child identifiers

The document does not follow this guidance from 8407bis:

  Identifiers SHOULD include complete words and/or well-known acronyms
  or abbreviations.  Child nodes within a container or list SHOULD NOT
  replicate the parent identifier.  YANG identifiers are hierarchical
  and are only meant to be unique within the set of sibling nodes
  defined in the same module namespace.

For example, consider

OLD:
      +--ro otsis!
      |  +--ro otsi-group* [otsi-group-id]
      |    +--ro otsi-group-id    string
      |    +--ro otsi* [carrier-id]
      |        +--ro carrier-id          uint16
      |        +--ro carrier-frequency?  union
      |        +--ro e2e-mc-path-id*      uint16
      +--ro templates
          +--ro roadm-path-impairments-sets
          |  +--ro roadm-path-impairments-set*
          |          [roadm-path-impairments-set-id]


NEW:
      +--ro otsis!
      |  +--ro otsi-group* [id]
      |    +--ro id    string
      |    +--ro otsi* [carrier-id]
      |        +--ro carrier-id          uint16
      |        +--ro carrier-frequency?  union
      |        +--ro e2e-mc-path-id*      uint16
      +--ro templates
          +--ro roadm-path-impairments-sets
          |  +--ro set*          [id]

There are many other such pattern in the document to be fixed.

# Configuration mention in a module with ro

For example, the module includes:

              enum 3r-or-tunnel {
                description
                  "The transponder can be configure to be used either
                    in an Optical Tunnel termination configuration or in
                    a 3R configuration.";

which configuration are you referring to here?

Idem for similar use in the module.

# IANA

OLD:
  name:      ietf-optical-impairment-topology
  namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-
  topology
  prefix:    oit
  reference: RFC XXXX (TDB)

NEW:
  name:      ietf-optical-impairment-topology
  namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-
  topology
  prefix:    oit
  maintained by IANA? N
  reference: RFC XXXX (TDB)

# The following are listed as normative, while they shouldn’t

  [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,
              .

  [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              .

  [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              .

  [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              .

Please double check the classification of your references.

Cheers,
Med

[Ballot comment]
Thanks for the work done in this document, it is vastly outside my comfort zone even with the detailed explanation of the problem space of section 2 (thanks, it was an interesting read). Two minor comments:

1) use of SVG graphics would complement nicely this I-D (the tool aasvg does magic !)

2) what is the difference between "contributors" and "additional authors" ?

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ccamp-optical-impairment-topology-yang-20. 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 on the IETF XML Registry group located at:

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

a single new namespace will be registered as follows:

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

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

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

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

a single new YANG module will be registered as follows:

Name: ietf-optical-impairment-topology
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-optical-impairment-topology
Prefix: oit
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-11-10):

From: The IESG
To: IETF-Announce
CC: ccamp-chairs@ietf.org, ccamp@ietf.org, draft-ietf-ccamp-optical-impairment-topology-yang@ietf.org, ketant.ietf@gmail.com, zhenghaomian@huawei.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Optical Impairment-aware Topology) to Proposed Standard


The IESG has received a request from the Common Control and Measurement Plane
WG (ccamp) to consider the following document: - 'A YANG Data Model for
Optical Impairment-aware Topology'
  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-11-10. 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


  In order to provision an optical connection through optical networks,
  a combination of path continuity, resource availability, and
  impairment constraints must be met to determine viable and optimal
  paths through the network.  The determination of appropriate paths is
  known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
  for a Wavelength Switched Optical Network (WSON), while it is known
  as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for a
  Spectrum Switched Optical Network (SSON).

  This document provides a YANG data model for the impairment-aware TE
  topology in optical networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-optical-impairment-topology-yang/



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

# 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?
 
  - Yes, this document has broad agreement, with support from experts in multiple companies with quite many iterations of discussions. Weekly calls have been done for years, with consensus achieved during the WG last call.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  - There is no controversy detected.

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.)
 
  - There is no threat on this work.

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)?
 
  - There is no evidence before the publication of this work. The effort from top vendors over years partially demonstrate the necessity of this work, and will be at least some considerations for implementation plan.

## 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.
 
  - There could be some relation with RFC9093 (and its bis), RFC9094 within ccamp working group, and are carefully managed.

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.
 
  - it passed the review from rtgdir and YANG doctor.

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]?
 
  - there is no error/warnings reported. The YANG module is in compliance with RFC8342.

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.
 
  - There is YANG doctor review, and RFC8407 check list is completed.

## 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 WG has been working on it for a long time. This work is ready to be handed off to AD.

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?

- Not detected so far.

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?

- It should be the 'proposed standard'. This RFC is standardizing the data model on the interfaces.

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 polls were done when the work is adopted by the WG, and the WG last call. All the feedback are reflected on the WG mailing list.

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, and there is 5 authors on the front page.

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

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

- The current references are in the correct places.

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 normative references are available to anyone.

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?

- Yes, see I-D.ietf-teas-rfc8776-update and I-D.ietf-ccamp-rfc9093-bis. These works are almost ready to publish.

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.

- No.

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

- This document request to register the ietf-optical-impairment-topology YANG module.

[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?
 
  - Yes, this document has broad agreement, with support from experts in multiple companies with quite many iterations of discussions. Weekly calls have been done for years, with consensus achieved during the WG last call.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
  - There is no controversy detected.

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.)
 
  - There is no threat on this work.

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)?
 
  - There is no evidence before the publication of this work. The effort from top vendors over years partially demonstrate the necessity of this work, and will be at least some considerations for implementation plan.

## 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.
 
  - There could be some relation with RFC9093 (and its bis), RFC9094 within ccamp working group, and are carefully managed.

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.
 
  - it passed the review from rtgdir and YANG doctor.

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]?
 
  - there is no error/warnings reported. The YANG module is in compliance with RFC8342.

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.
 
  - There is YANG doctor review, and RFC8407 check list is completed.

## 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 WG has been working on it for a long time. This work is ready to be handed off to AD.

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?

- Not detected so far.

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?

- It should be the 'proposed standard'. This RFC is standardizing the data model on the interfaces.

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 polls were done when the work is adopted by the WG, and the WG last call. All the feedback are reflected on the WG mailing list.

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, and there is 5 authors on the front page.

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

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

- The current references are in the correct places.

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 normative references are available to anyone.

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?

- Yes, see I-D.ietf-teas-rfc8776-update and I-D.ietf-ccamp-rfc9093-bis. These works are almost ready to publish.

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.

- No.

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

- This document request to register the ietf-optical-impairment-topology YANG module.

[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/

Changed document URLs from:

[u'yang-impact-analysis https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-optical-impairment-topology@2019-05-22.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ccamp-optical-impairment-topology-yang)', u'yang-module-metadata https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-optical-impairment-topology@2019-05-22.yang (Yang catalog entry for ietf-optical-impairment-topology@2019-05-22.yang)']

to:

yang-module-metadata https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-optical-impairment-topology@2019-05-22.yang (Yang catalog entry for ietf-optical-impairment-topology@2019-05-22.yang)
repository https://github.com/younglee-ietf/ietf-optical-impairment-yang/issues
yang-impact-analysis https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-optical-impairment-topology@2019-05-22.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ccamp-optical-impairment-topology-yang)

Changed document URLs from:

[u'yang-impact-analysis https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-optical-impairment-topology@2019-05-22.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ccamp-optical-impairment-topology-yang)', u'yang-module-metadata https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-optical-impairment-topology@2019-05-22.yang (Yang catalog entry for ietf-optical-impairment-topology@2019-05-22.yang)']

to:

repository https://github.com/younglee-ietf/ietf-optical-impairment-yang/issues
yang-impact-analysis https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-optical-impairment-topology@2019-05-22.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both (Yang impact analysis for draft-ietf-ccamp-optical-impairment-topology-yang)

Request for posting confirmation emailed to previous authors: Gert Grammel , ccamp-chairs@ietf.org, Julien Meuric , Haomian Zheng , Gabriele Galimberti , Giovanni Martinelli , Young Lee , Griseri Enrico , Italo Busi , Victor Lopezalvarez , Sergio Belotti , Nicola Sambo , Dieter Beller , Luc Auge

IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/mJcAfQ7ZFmkq37zgK7MOspObb1g

AUTHORS

Jonas Martensson jonas.martensson@ri.se https://mailarchive.ietf.org/arch/msg/ccamp/c-EVwqR6QwDgyVz9yLLoPxZktYA
Young Lee leeyoung@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/LJ25Yd0LinPyX1HA05ibNwZSqy8
Haomian Zheng zhenghaomian@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/EYqK4gHKNPsdHd57qAdkEPHhhuQ
Italo Busi Italo.Busi@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/OZ3rIfshPfWq0MwQCgek-B23Qx4
Nicola Sambo nicosambo@gmail.com https://mailarchive.ietf.org/arch/msg/ccamp/d8MocoMQpTBC6OtBzxDrPlQ0HIg
Victor Lopez victor.lopezalvarez@telefonica.com https://mailarchive.ietf.org/arch/msg/ccamp/TcoP0gYOZ90R_5sWTK7szUSbybU
Gabriele Galimberti ggalimbe@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/iNUMolstXIM1_AsTnTZUUIjEHZQ
Giovanni Martinelli giomarti@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/GYLqPPt3uRYy6nHsb3IeURED7pw
AUGE Jean Luc jeanluc.auge@orange.com https://mailarchive.ietf.org/arch/msg/ccamp/CaEDR3JomG52Ag83spSuuuUTjbQ
Gert Grammel ggrammel@juniper.net https://mailarchive.ietf.org/arch/msg/ccamp/cuzJU6A9mf8XETBxlY8WW04qjcA
LE ROUZIC Esther esther.lerouzic@orange.com https://mailarchive.ietf.org/arch/msg/ccamp/xEG9bt3PDBPQTrnZR9hNdTuYSzg
Julien Meuric julien.meuric@orange.com https://mailarchive.ietf.org/arch/msg/ccamp/vV1b-JX8LmPqFrf2nmfqqIaVBfQ
Dieter Beller dieter.beller@nokia.com https://mailarchive.ietf.org/arch/msg/ccamp/q7CGlqYs1nzD3riBTUR8mCVZm4k
Sergio Belotti Sergio.belotti@nokia.com https://mailarchive.ietf.org/arch/msg/ccamp/ZpcNlTPqkGThQ2Ao4E_scKKhLFw
Griseri Enrico enrico.griseri@nokia.com https://mailarchive.ietf.org/arch/msg/ccamp/mTmS0QB4pTwthpQNLJnUfB7g8HM