[CCAMP]Re: Mahesh Jethanandani's Discuss on draft-ietf-ccamp-optical-impairment-topology-yang-20: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Mahesh,

Can you please check/review the updated v21 posted?
https://www.ietf.org/archive/id/draft-ietf-ccamp-optical-impairment-topology-yang-21.html

Does it address your DISCUSS and other comments?

Thanks,
Ketan


On Mon, Feb 9, 2026 at 3:28 PM Dieter Beller (Nokia) <
[e-mail]> wrote:

> Hi Mahesh,
>
> thanks a lot you for your review!
>
> Please find our response to your comments copied from
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/203
> <https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/200>
> below.
> (For each IESG review, we created an open issue on our GitHb repository
> -->
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues
> )
>
> We hope that your comments are adequately addressed and resolved.
>
> Thanks,
> Dieter on behalf of the co-authors
>
> ------------------------------
>
> 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.
>
> Should have been:
>
> <CODE BEGINS> file "[e-mail]"
> <[e-mail]>
>
> The date should be updated each time the YANG module is updated to match
> the date of the revision within the YANG module
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> update the XML file -
>    fixed based on latest YANG revision.
>
>
>    - 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"
>
> Authors: No action based on the mailing list discussion.
>
> Since this is not the first time the version of layer0-types has been an
> issue, an alternative solution could be to add a comment, similar with the
> one added in draft-ietf-ccamp-dwdm-if-param-yang-14.
>
> However, since publication has been requested for this draft, we would
> need also to add another note to the RFC Editor to remove the comment
> before publication.
>
> 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.
>
> The list of imported modules is already provided in table 1
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> : add ietf-te-types to
>    table 1 and propose a reply to this comment - updated table:
>
>     +==========+=====================+================================+
>     | Prefix   | YANG module         | Reference                      |
>     +==========+=====================+================================+
>     | oit      | ietf-optical-       | [RFCXXXX]                      |
>     |          | impairment-topology |                                |
>     +----------+---------------------+--------------------------------+
>     | l0-types | ietf-layer0-types   | [I-D.ietf-ccamp-rfc9093-bis]   |
>     +----------+---------------------+--------------------------------+
>     | nw       | ietf-network        | [RFC8345]                      |
>     +----------+---------------------+--------------------------------+
>     | nt       | ietf-network-       | [RFC8345]                      |
>     |          | topology            |                                |
>     +----------+---------------------+--------------------------------+
>     | te-types | ietf-te-types       | [I-D.ietf-teas-rfc8776-update] |
>     +----------+---------------------+--------------------------------+
>     | tet      | ietf-te-topology    | [RFC8795]                      |
>     +----------+---------------------+--------------------------------+
>
>               Table 1: Prefixes and corresponding YANG modules
>
> Section 4, paragraph 4
>
>     Editor:   Young Lee <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Haomian Zheng <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Nicola Sambo <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Victor Lopez <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Gabriele Galimberti <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Giovanni Martinelli <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Jean-Luc Auge <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Le Rouzic Esther <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Julien Meuric <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Italo Busi <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Dieter Beller <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Sergio Belotti <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Griseri Enrico <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>
>     Editor:   Gert Grammel <[[e-mail]](mailto:[e-mail])> <[[e-mail]](mailto:[e-mail])>";
>
> How come the document has 5 authors but 14 editors?
>
> Authors: Because the RFC editors guidelines limit the number of number of
> authors in the front page (all the other authors should be listed as
> contributors) while there is no limitation on the number of editors for the
> YANG modules nor a differentiation between authors/contributors/editors as
> per the template in appendix B of RFC8407-bis.
>
> 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.
> Please move the mandatory statement out of case and put it under the choice
> statement
>
> Authors: The intention is to indicate which data node is mandatory or
> optional to be present when a specific case is chosen (e.g. the
> power-spectral-density).
>
> 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.
>
> Authors> This container represent a network-type
> "optical-impairment-topology" that has to augment the generic container
> "network-type". "Network types SHOULD always be represented using presence
> containers, not leafs of type "empty"". See RFC8345 section 4.1 for further
> details .
>
> 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?
>
> Authors> See above comment. You need to instantiate the presence container
> , in order to have the when statement as true.
>
> ------------------------------
> 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.
>
> Authors: No actions taken on the draft.
>
> 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.
>
> Authors: Ok for us to add the RFC number in the Abstract (without the
> square brackets) but then we can miss them in the references section
>
> Moreover, we are not sure we can remove this sentence from the
> Introduction. According to section 4.3 of RFC 7322:
>
>    Abstract is not a substitute for an Introduction; the
>    RFC should be self-contained as if there were no Abstract
>
> 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).
>
> Authors: It is YANG 1.1. Should this be stated in the text? We have not
> seen other RFCs specifying the version of the YANG data model. We will fix
> the YANG to be always all caps.
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> fixed YANG to be
>    always all caps - fixed.
>
> 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.
>
> Authors: We will fix referencing RFC6241.
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> c/RFC8341/RFC6241/ -
>    fixed.
>
> 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.
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> propose rephrasing
>    this sentence - proposed new text:
>
>    Optical data plane interoperability, particularly for optical
>    transponders across multiple vendors, is a complex challenge that
>    typically necessitates joint engineering regardless of control and
>    management plane capabilities.  However, the YANG data model defined
>    in this document provides the essential optical impairment data
>    required for impairment-aware path computation including optical
>    transponder interoperability if it exists.
>
> 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?
>
> Authors: We will delete "where possible"
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> remove "where
>    possible" - removed.
>
> 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".
>
> Authors: Ok, we will remove " i.e., not configurable (read-write)". We
> will also update the Abstract to make it more clear the scope of this YANG
> data model.
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> remove " i.e., not
>    configurable (read-write)" and update the Abstract
>
> Added a sentence at the end of the Abstract:
>
> 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 supporting the provisioning
>    of optical connections in a impairment-aware traffic engineering
>    topology (TE topology) for optical networks.  It augments the
>    technology agnostic YANG Data Model for Traffic Engineering (TE)
>    Topologies as defined in [RFC8795].  The topology YANG model provides
>    read-only topology data including optical impairments that can be
>    used for example by a Path Computation Engine (PCE) for calculating
>    an optically feasible path for a new connection before it is
>    established through an optical network.
>
> 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.
>
> Authors: Based on a comment from Med, we have removed the second part of
> this sentence on NMDA (i.e., "according to the new Network Management
> Datastore Architecture [RFC8342]"). This was already fixed based on another
> review comment.
>
> 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.
>
> Authors: We will remove the "and is applicable to devices and network
> controllers" to avoid confusion. We think that referencing RFC8969 should
> be enough to distinguish the role of network and device models and their
> relationship, with no need to repeat here.
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> Remove "and is
>    applicable to devices and network controllers" - removed.
>
> 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.
>
> Authors: Ok to move the tree diagram to an appendix. We will provide a
> snapshot of the different aspects of the model in a separate section. We
> would avoid to have tree snippets since they are difficult to be maintained
> aligned with the possible updates of the model.
>
>    -
>    @sergiobelotti <https://github.com/sergiobelotti> : check the proposed
>    reply to Med about the model overview section.
>
> 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?
>
> Authors: We have updated the description to become: "The attributes of an
> amplifier."
>
> 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.
>
> Authors: Added a 'config false' statement.
>
> Could you please provide us the list of the other attributes where you
> think we should add the 'config false' statement?
>
> Also, what does it mean for the attribute to be "not present"? How do you
> make sure the node is "not present"?
>
> Authors: It means not present in the YANG data store.
>
> 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.
>
> Authors: The document has already gone through IETF LC YD reviews:
>
>
> https://datatracker.ietf.org/doc/review-ietf-ccamp-optical-impairment-topology-yang-18-yangdoctors-lc-vasko-2025-04-24/
>
> The comments have been addressed:
>
>
> https://mailarchive.ietf.org/arch/msg/yang-doctors/B0A3wB6WNzawko7jSjlPUgbj7-Q/
>
> 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.
>
>
>    -
>    Search for PMD reference
>
> 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."
>
>    -
>    Search for CD reference
>
> 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."
>
>    -
>    Search for PDL reference
>
> 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?
>
> Authors> We will fix for the next update.
>
> 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?
>
> Authors> The descriptions of some of the same leaves in the 2 groupings
> are different . If you prefer we could define a common grouping and refine
> the descriptions when using it.
>
> 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?
>
> Authors> This type is used only once , no need to create a typedef.
>
> 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?
>
> Authors> The reason to use the grouping is to improve readability of the
> code when too much nesting is present as in this case.
>
> 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'?
>
> Authors> We will update the description as "Unique id of the element, when
> known.";
>
> 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.
>
> Authors: We will align the section with the template in RFC8407-bis
>
> ------------------------------
> 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.
>
> Authors: The referenced sections below do not always match the section
> numbers in draft-ietf-ccamp-optical-impairment-topology-yang-20 so we have
> searched the quoted text and fixed when we have found it.
>
> Section 2.3.4, paragraph 1
>
> n amplifiers are widely used. Raman amplifiers have become attractive due
> to ^^^^^^^^^^^^^^^^ The genitive ('s) may be missing.
>
> Authors: No need for genitive in this sentence: Raman is an adjective.
>
> Section 2.3.4, paragraph 2
>
> ly more expensive than EDFAs. Raman amplifiers are distributed amplifiers
> whe ^^^^^^^^^^^^^^^^ The genitive ('s) may be missing.
>
> Authors: Same as above
>
> 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.
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - paragraph changes
>    based on another comment:
>
>    ILAs may have a variable optical attenuator on the ingress side (in-
>    voa attribute) allowing control of the input power of the WDM signal
>    (OMS MCG) entering the gain stage of the ILA.  It may also have a
>    variable optical attenuator on the egress side, which allows control
>    of the optical power of the WDM output signal (OMS MCG) of the ILA.
>    The actual-gain attribute reflects the gain of the ILA gain stage and
>    does not include the attenuation of the in-voa and/or out-voa.
>
> 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".
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - text updated as
>    suggested.
>
> 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.
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - text updated as
>    suggested.
>
> 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".
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - text updated as
>    suggested.
>
> 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".
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> c/This should,
>    however, only be an done in exceptional cases/This should, however, only be
>    done only in exceptional cases/ - text updated as suggested.
>
> 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.
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - already fixed based
>    on another review comment:
>
> 2.6.3.  Explicit Modes
>
>    The explicit mode allows the encoding, explicitly, of any subset of
>    parameters e.g., FEC type, Modulation type, etc, to enable a
>    controller entity to check for interoperability by means outside of
>    this document. ...
>
> 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.".
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - fixed.
>
> 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".
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - fixed.
>
> 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".
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller>
>
> Possible rephrasing:
>
> OLD
>
> then selects the wavelength that is of interest by deflecting it from the
> original optical path,
>
> NEW
>
> then selects, by deflecting it from the original optical path, the
> wavelength that is of interest,
>
> Paragraph updated as follows:
>
> 2.8.  Wavelength Selective Switch (WSS)/Filter
>
>    A WSS is a device that dynamically routes individual wavelengths from
>    a common input fiber to any of several output ports without
>    converting them into electrical signals.  The WSS/Filter is internal
>    to a ROADM device.  This document does not model the internals of a
>    ROADM's WSS.
>
> 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".
>
> Authors: In this context, 'dedicated' is an adjective and not a verb.
>
> 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.
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - "dedicated" replaced
>    by "specific":
>
> 2.11.1.  Individual OTSi Protection
>
>    Individual OTSi protection is a protection architecture where an
>    individual OTSi signal is protected as described in Appendix III of
>    ITU-T Recommendation G.873.1 [G.873.1].  This protection architecture
>    requires specific photonic protection functions in the optical domain
>    that are typically provided by specific protection hardware.  These
>    photonic protection functions are a photonic splitter function
>    splitting the OTSi signal in the transmit direction and a photonic
>    selector function selecting the OTSi signal in the receive direction
>    from one of the two protection legs between the two protection
>    functions terminating the individual OTSi protection.  This
>    individual OTSi protection scheme can be considered as a photonic 1+1
>    protection scheme (1+1 sub-network connection protection (SNCP) in
>    ITU-T terminology).
>
> 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.
>
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> - text updated as
>    suggested.
>
> 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".
>
> Authors: We cannot find this text in the draft.
>
> 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".
>
> Authors: fixed
>
> 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".
>
> Authors: Changed as "It represents the total output power ..."
>
> Section 2.11.2.2, paragraph 22
>
> amplifier inferred to the add port. This permits add path OSNR calculation
> b ^^^^ Did you mean "these"?
>
> Authors: We think the singular 'This' is correct since it refers to the
> 'noise figure' defined in the previous sentence.
>
> 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".
>
> Authors: Fixed as "The max value corresponds to the worst case"
>
> Section 2.11.2.2, paragraph 22
>
> raints. The max value correspond to worst case expected loss, including
> ampli ^^^^^ A determiner may be missing.
>
> Authors: Fixed as above
>
> 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.
>
> Authors: Fixed
>
> 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.
>
> Authors: Fixed
>
> 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".
>
> Authors: Fixed
>
> 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".
>
> Authors: Fixed
>
> 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.
>
> Authors: Fixed
>
>    -
>    @dieterbeller <https://github.com/dieterbeller> Fix a similar issue in
>    section 2.3.2 (forth line): "The relationship between the OTSiG and the
>    the" - fixed.
>
> 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".
>
> Authors: Fixed by addressing a comment above (removing the word configured)
>
> 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".
>
> Authors: Fixed
>
> 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.
>
> Authors> We will fix both.
>
> See:
> https://mailarchive.ietf.org/arch/msg/ccamp/EPQTdNTPrlK5yVeOBR8N6nQAKvU/
> See:
> https://mailarchive.ietf.org/arch/msg/ccamp/zi-mX5TBzy9Y_16zKNqyt_LPbXU/
>
>
> On 18-Nov-25 00:34, Mahesh Jethanandani via Datatracker wrote:
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-ccamp-optical-impairment-topology-yang-20: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-ccamp-optical-impairment-topology-yang/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 4, paragraph 0
>
>    <CODE BEGINS> 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" <snip>
>
> Separately, please list all the RFCs whose modules are imported in the document
> at the begining of the section, and outise the <CODE BEGINS> block so they can
> be normatively referenced.
>
> Section 4, paragraph 4
>
>         Editor:   Young Lee <[e-mail]> <[e-mail]>
>         Editor:   Haomian Zheng <[e-mail]> <[e-mail]>
>         Editor:   Nicola Sambo <[e-mail]> <[e-mail]>
>         Editor:   Victor Lopez <[e-mail]> <[e-mail]>
>         Editor:   Gabriele Galimberti <[e-mail]> <[e-mail]>
>         Editor:   Giovanni Martinelli <[e-mail]> <[e-mail]>
>         Editor:   Jean-Luc Auge <[e-mail]> <[e-mail]>
>         Editor:   Le Rouzic Esther <[e-mail]> <[e-mail]>
>         Editor:   Julien Meuric <[e-mail]> <[e-mail]>
>         Editor:   Italo Busi <[e-mail]> <[e-mail]>
>         Editor:   Dieter Beller <[e-mail]> <[e-mail]>
>         Editor:   Sergio Belotti <[e-mail]> <[e-mail]>
>         Editor:   Griseri Enrico <[e-mail]> <[e-mail]>
>         Editor:   Gert Grammel <[e-mail]> <[e-mail]>";
>
> 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.
>
>
> ----------------------------------------------------------------------
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool&data=05%7C02%7Cdieter.beller%40nokia.com%7Cbd5a145d76744d4656f208de2631e103%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638990192844051672%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=54kCLBA1UIwCWyK%2BG41CA%2Fk3gwkb69Tfs2NL9nuj0yU%3D&reserved=0 <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.
>
>
>
>
>
> --
>
> * Dieter Beller*
> Open Agent & Routing Project Manager
> Network Infrastructure - Optical Networks Division
> Contact number: [phone] | Teams Chat
> <https://teams.microsoft.com/l/chat/0/0?users=[e-mail]>
> [image: Nokia]
>
> At Nokia, we create technology that helps the world act together.
>
> Nokia Solutions and Networks GmbH & Co. KG
> Magirusstraße 8, 70469 Stuttgart
> Sitz der Gesellschaft: München / Registered office: Munich
> Registergericht: München / Commercial registry: Munich, HRA 88537
> WEEE-Reg.-Nr.: DE 52984304
> Persönlich haftende Gesellschafterin / General Partner: Nokia Solutions
> and Networks Management GmbH
> Geschäftsleitung / Board of Directors: Eleftherios Papadopoulos
> Vorsitzender des Aufsichtsrats / Chairman of supervisory board:
> Hans-Jürgen Bill
> Sitz der Gesellschaft: München / Registered office: Munich
> Registergericht: München / Commercial registry: Munich, HRB 163416
>
> This e-mail and its attachments, if any, may contain confidential
> information.
> If you have received this e-mail in error, please notify us and delete or
> destroy the e-mail and its attachments, if any, immediately.
> If you have received this e-mail in error, you must not forward or make
> use of the e-mail and its attachments, if any.
>
>