Hi Elwyn,
meanwhile we did address and resolve all your review comments - there is
one exception:
The additional blank in the figure titles of Figures 15-18 (between
"WDM-TE-" and "node" --> "WDM-TE- node") seems to be a bug of the IETF
xml2rfc tool.
Please find our response to your comments copied from
https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/201 below.
We hope that your comments are adequately addressed and resolved.
Thanks,
Dieter on behalf of the co-authors
------------------------------------------------------------------------
Document: draft-ietf-ccamp-optical-impairment-topology-yang
Title: A YANG Data Model for Optical Impairment-aware Topology
Reviewer: Elwyn Davies
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair. Please treat these comments just like
any other last call comments.
For more information, please see the FAQ at
https://wiki.ietf.org/en/group/gen/GenArtFAQ.
Document: draft-ietf-ccamp-optical-impairment-topology-yang-20
Reviewer: Elwyn Davies
Review Date: 2025-11-15
IETF LC End Date: 2025-11-10
IESG Telechat date: 2025-11-20
Summary:Ready with nits as far as the explanatory text is concerned.
I am afraid that my knowledge of the deep technology of fibre optic
networks is about 20 years out of date so I cannot offer any
opinions of the accuracy of the technical details of the YANG and
its appropriateness for current optical network configuration - but
it seems to make sense and provide the sort of support that might be
needed. I apologise for the lateness of the review - I had to do a
certain amount of background catch-up - and it is a meaty document!
There appear to be a few places where some additional pointers to
external document might be needed for things which may be common
knowldege for afficianados but are less so for newbies.
Major issues:
None
Minor issues:
None
Nits/editorial comments:
General: s/e.g. /e.g., / (7 cases starting in s1.1)
General: s/like/such as/ (6 cases starting in para 2 of s2.3.1, next
to last para of s2.4, paras 1 and 2 of s2.6. last para of s2.6.1,
para 1 of s2.6.2 )
Abstract: It would be worth expanding TE (Traffic Engineering) in
the abstract and mentioning that, in general. it augments RFC 8795.
Abstract updated:
|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]. |
Abstract, para 2: Suggest s/for the impairment-aware/supporting the
provisioning of optical connections in impairment-aware/
See updated Abstract above.
s1, first sentence: s/a wavelength/wavelength/
Text updated as suggested.
s1, para 4: This para refers specifically to WSONs and omits SSONs.
Does the MDSC technology not apply to SSONs?
Text updated:
|The intent of this document is to provide a YANG data model, that can
be utilized by a Multi-Domain Service Coordinator (MDSC) to collect WSON
or SSON 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 [RFC6241] or a RESTCONF interface [RFC8040]. |
s1. next to last para: It would be more elegant to s/E.g../For example,/
Text updated as suggested.
s1, last para: s/new/second generation/ [new is not future proof]
"new removed" - para updated:
|This document defines one YANG module: ietf-optical-impairment-
topology (Section 3) according to the Network Management Datastore
Architecture as defined in [RFC8342]. |
s1.1, para 14, last sentence: The phrase 'may only contain OTs' gave
me pause.
Just checking that this is intended to imply that this is one
possible case of the node. If so, it could be better to say 'might
only'. 'May only' got me thinking that this could be a restriction
on the make up.
Your interpretation is correct - text updated as suggested.
s1.1, para 16 and s2.3.3, para 3: the XML section cross reference
inserts 'Section xxxx' automatically so remove 'section' before the
cross reference.
Issue fixed in the XML file.
s2.1, para 2: Expand DWDM on first use.
Text updated as suggested.
s2.1. Figure 1: Quibble: Define MCG before OTS MCG and OMS MCG.
Text updated as suggested.
s2.3, Figures 2, 3 and 4: Do the Kn labels have any significance?
Figures updated: Kn labels removed from the figures
s2.3, Figures 2 and 3: Do the X markings have any significance
beyond marking the centre frequency of the channel?
Figures updated: "X: indicates the center of the frequency slot" added
s2.4, para 1: s/today/at the time of writing/
Text updated as suggested.
s2.3, para 8: s/in transmit direction/in the transmit direction/;
Text updated as suggested.
s2.4, para 10: s/allowing to control/allowing control of/, s/which
allows to control the/which allows control of the/
Text updated as suggested.
s2.4, para before Figure 5: s/This filter and/These filter and/
Text updated as suggested.
s2.6, para 1: s/like for example/such as, for example,/
Text updated as suggested.
s2.6, para 1: The term 'client layer' makes its first appearance in
this document here. It is not really inherited from any of the RFCs
referred to in the Terminology section. The only mention I could
find of the term is a definition specific to RFC 7698 given in
Section 1 of that document. I think it
needs a definition. Further, I am not sure what the phrase
'addressing layer
0 aspects of transponders' actually applies to. Is this something
which ought to be said at the beginning about the scope of the whole
document. i.e., that it addresses just the layer 0 aspects of all
components mentioned? Please clarify.
*
To be addressed
s2.6, para 3: The etc at the end of this paragraph leaves one
hanging without complete knowledge of what properties are covered.
Will I find out how it is completed later? If so some pointers to
sections where the complete lists can be seen would be useful.
The list is intentionally incomplete.
Paragraph updated as follows:
|A transponder is typically characterized by its data/symbol rate and
the maximum distance the signal can travel. Other transponder properties
are for example but are not limited to: carrier frequency range for the
optical channel, output power per channel, measured input power,
modulation scheme, Forward Error Correction (FEC), etc. |
s2.6.1, para 1: Expand SDO on first use (not deemed to be well-known).
Text updated as suggested: "by a Standards Development Organization (SDO)"
s2.6.1, para 1: s/to consider other/consideration of other/, s/will
be available/might be available/
Text updated as suggested.
s2.6.1, para 1: It might be worth repeating the definition of
"Transversely compatible dense wavelength division multiplexing"
(DWDM) i.e., that it is a standard that ensures DWDM equipment from
different vendors can work together in a network.
Paragraph updated as follows:
|A standard mode is related to an optical specification developed by a
Standards Development Organization (SDO). Currently, the "Standard
Modes" can only be referred to ITU-T Recommendation G.698.2 [G.698.2]
since ITU-T Recommendation G.698.2 is the only standard defining
"Standard Modes" today. Nothing is precluding, however, consideration of
other specifications provided by any other SDO in the Standard Mode
context as soon as such specifications might be available. An
application code as defined in ITU-T G.698.2 [G.698.2] represents a
standard ITU-T G.698.2 optical interface specification towards the
realization of transversely compatible DWDM systems that it is a
standard that ensures transceivers from different vendors can work
together in a DWDM network. Two transceivers supporting the same
application code and a line system matching the constraints, defined in
ITU-T G.698.2, for that application code will interoperate. As the
characteristics are encoded in the application code, the YANG model in
this document only defines a string, which represents that application
code. |
s2.6.1, para 2, last sentence: s/as transceiver capability/as a
transceiver capability/
Text updated as suggested.
s2.6.2, 1st bullet: Expand FEC.
FEC expanded where it occurs for the first time in the document -->
s2.6, para 3.
s2.6.3, para 1: s/allows to encode, explicitly,/allows the encoding,
explicitly, of/
Text updated as suggested.
s2.6.4, para 4: s/allows to describe/allows the description of/
Text updated as suggested.
s2.7, para 6 (just before Figure 7): s/as the transmitter/than the
transmitter/
Text updated as suggested.
s2.7, para 7: s/the capability whether/the capability that/
Text updated as suggested.
s2.10, para 4: s/ Section 4 intend/Section 4 intends/
Text updated as suggested.
s2.10, Figures 9 and 10: What is the significance of the term
'Colored OT'?
Is this known from some other context?
"Colored" removed - not relevant
s2.11.1, para 1: s/in transmit direction/in the transmit direction/;
s/in receive direction/in the receive direction/
Text updated as suggested.
s2.11.1, para 3: s/as leaf list of the otsi/as a leaf list of the OTSi/
Text updated as suggested.
s2.11.1, para 4: s/in forward direction/in the forward direction/;
s/in reverse direction/in the reverse direction/
Text updated as suggested.
s2.11.1, bullet points 1-3: s/in reverse direction/in the reverse
direction/ (3
places)
Text updated as suggested.
s2.11.1, para 11 and s2.11.1.2, para 5: s/Like/Similarly/
Text updated as suggested.
s2.11.1, para 11: s/in forward and reverse direction/in the forward
and reverse directions/
Text updated as suggested.
s2.11.1, last para: s/in following/in the following/; s/provided how
these/provided as to how these/
Text updated as suggested.
s2.11.1.1, para 5: s$in transmit/forward direction$in the
transmit/forward direction$; s$in receive/reverse direction$in the
receive/reverse direction$
Text updated as suggested.
s2.11.1.1. para 7: Does the term local-link-connectivity list need a
reference to its definition which may be in
draft-ietf-teas-yang-te-topo or RFC 8795?
Text updated:
|For unprotected TTPs associated with an optical transceiver, the
local-link-connectivity list (LLCL) as defined in [RFC8795] describes
the potential connectivity between the TTP and the LTPs of the WDM-
TE-node that are the local end-points of the TE-links (OMS MCGs)
interconnecting the WDM-TE-node with its neighbors, also often called
degrees of the WDM-TE-node as opposed to its add-drop ports. |
s2.11.1.2, para 4: s$in transmit/forward direction$in the
transmit/forward direction$; s$in receive/reverse direction$in the
receive/reverse direction$
Text updated as suggested.
s2.11.1.2 para 6: s/the protected ad-drop/the protected add-drop/
Text updated as suggested.
s2.11.1.1 and .2, titles of Figures 15-18: s/WDM-TE node/WDM-TE-node/
*
artifact of the IETF xml tool (don't know how to fix it):
|<figure align="center" title="OT and OTSi protection/ROADM functions
are in two adjacent WDM-TE-node (remote OT, transmit direction)"> |
Even the new figure format leads to the same result:
|<figure align="center"> <name> OT and OTSi protection function are an
integral part of the WDM-TE-node (transmit direction) </name> |
|WDM-TE-Node +---------------------------------------------------------+
| ROADM | | Local OT Splitter +--------------+ | | +------------+
+--------+ | | Line | | | TTP| | ---o-->o------\ | LTP 1 | | | +----| |
/ | | \------o-------o-> --o-->| | Tx o--->o---o | | | | | | +----| | \
| | | | <-o---| | Rx o | ---o-->o---\ | Line | | | +----| +--------+ | \
| LTP 2 | | | | | \ o-------o-> | +------------+ internal | \ | | | AD
ports o \ | | | | \ | Line | | | \ | LTP 3 | | | \---o-------o-> | o | |
| | | | | +--------------+ |
+---------------------------------------------------------+ Figure 15:
OT and OTSi protection function are an integral part of the WDM-TE- node
(transmit direction) |
s2.11.1.3, paras 1 and 4: Do 'The difference compared to use case
(i)' and 'in the same way as for use case (i)' refer (again) to
s2.11.1.1 - there doesn't seem to be any usage of (i) as a bullet
label around here.
2.11.1.3 Text updates:
|The use case illustrated in Figure 19 is similar to the use case in
Section 2.11.1.1. The difference is that WDM-TE-Node-1 does not contain
the ROADM function but contains: |
and
|WDM-TE-Node-1 can be a data center device or a router device that is
supporting 1+1 OTSi protection for its OTs while WDM-TE-Node-2 is a
WDM-TE-node providing add-drop ports for remote OTs as depicted in
Figure 9. WDM-TE-Node-1 and WDM-TE-Node-2 are interconnected via two
separate TE-links, each carrying a single OTSi signal. The protection
configuration for the protected TTP in WDM-TE-Node-1 can be described in
the same way as for the use in Section 2.11.1.1 using the
local-link-connectivity list. |
s2.11.2.1, para 1: Missing closing bracket after 'TE-link
("te-link-attributes"'
Text updated as suggested.
s3 in 'grouping amplifier-params: container operational: leaf
type-variety'
s/This attributes/This attribute/
*
YANG file update required
YANG updated as suggested
s3 in 'grouping oms-element: elt-index': s/allowing to sort/allowing
the sorting/
*
YANG file update required
YANG updated as suggested
s3 in 'container transponders: list transponder:leaf
termination-type-capabilities: enum 3r-or-tunnel:" s/can be
configure/can be configured/
*
YANG file update required
YANG updated as suggested
s3 in 'container transponders:list transceiver:leaf
explicit-transceiver-mode-ref:" s/The refernce to the explicit/The
reference to the explicit/
*
YANG file update required
YANG updated as suggested
s3 in 'container transponders:container regen-groups:leaf regen-metric:'
s/among different group/among different groups/
*
YANG file update required
YANG updated as suggested
s3 in 'container transponders:container regen-groups:leaf-list
transponder-ref:' s/The list of transponder/The list of transponders/
*
YANG file update required
YANG updated as suggested
Appendix B: There does not appear to be a reference to Appendix B in
the body of the document. I would have expected that there would
have been a pointer to it somewhere!
New paragraph added below the 1st paragraph of section 2.10.2:
|Appendix B provides a modeling example for a configuration where the
optical transponders and the ROADM are different WDM-TE-nodes (remote OT
configuration). |
See:
https://mailarchive.ietf.org/arch/msg/ccamp/pi3bqKJLZ2TiUReB0LsuKjOcEB8/
------------------------------------------------------------------------
On 09-Jan-26 18:55, Dieter Beller (Nokia) wrote:
Hi Elwyn,
Happy New Year and thanks a lot you for your review!
Please find our response to your Genart review comments on GitHub:
https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/201.
There are still a few comments we will address in the coming days.
(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 those comments we already resolved adequately addressed
your comments.
You will be notified again when the remaining comments will have been
resolved too.
Thanks,
Dieter on behalf of the co-authors
On 16-Nov-25 10:40, Elwyn Davies 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.
Document: draft-ietf-ccamp-optical-impairment-topology-yang
Title: A YANG Data Model for Optical Impairment-aware Topology
Reviewer: Elwyn Davies
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-ccamp-optical-impairment-topology-yang-20
Reviewer: Elwyn Davies
Review Date: 2025-11-15
IETF LC End Date: 2025-11-10
IESG Telechat date: 2025-11-20
Summary:Ready with nits as far as the explanatory text is concerned. I am
afraid that my knowledge of the deep technology of fibre optic networks is
about 20 years out of date so I cannot offer any opinions of the accuracy of
the technical details of the YANG and its appropriateness for current optical
network configuration - but it seems to make sense and provide the sort of
support that might be needed. I apologise for the lateness of the review - I
had to do a certain amount of background catch-up - and it is a meaty document!
There appear to be a few places where some additional pointers to external
document might be needed for things which may be common knowldege for
afficianados but are less so for newbies.
Major issues:
None
Minor issues:
None
Nits/editorial comments:
General: s/e.g. /e.g., / (7 cases starting in s1.1)
General: s/like/such as/ (6 cases starting in para 2 of s2.3.1, next to last
para of s2.4, paras 1 and 2 of s2.6. last para of s2.6.1, para 1 of s2.6.2 )
Abstract: It would be worth expanding TE (Traffic Engineering) in the abstract
and mentioning that, in general. it augments RFC 8795.
Abstract, para 2: Suggest s/for the impairment-aware/supporting the
provisioning of optical connections in impairment-aware/
s1, first sentence: s/a wavelength/wavelength/
s1, para 4: This para refers specifically to WSONs and omits SSONs. Does the
MDSC technology not apply to SSONs?
s1. next to last para: It would be more elegant to s/E.g../For example,/
s1, last para: s/new/second generation/ [new is not future proof]
s1.1, para 14, last sentence: The phrase 'may only contain OTs' gave me pause.
Just checking that this is intended to imply that this is one possible case of
the node. If so, it could be better to say 'might only'. 'May only' got me
thinking that this could be a restriction on the make up.
s1.1, para 16 and s2.3.3, para 3: the XML section cross reference inserts
'Section xxxx' automatically so remove 'section' before the cross reference.
s2.1, para 2: Expand DWDM on first use.
s2.1. Figure 1: Quibble: Define MCG before OTS MCG and OMS MCG.
s2.3, Figures 2, 3 and 4: Do the Kn labels have any significance?
s2.3, Figures 2 and 3: Do the X markings have any significance beyond marking
the centre frequency of the channel?
s2.4, para 1: s/today/at the time of writing/
s2.3, para 8: s/in transmit direction/in the transmit direction/;
s2.4, para 10: s/allowing to control/allowing control of/, s/which allows to
control the/which allows control of the/
s2.4, para before Figure 5: s/This filter and/These filter and/
s2.6, para 1: s/like for example/such as, for example,/
s2.6, para 1: The term 'client layer' makes its first appearance in this
document here. It is not really inherited from any of the RFCs referred to in
the Terminology section. The only mention I could find of the term is a
definition specific to RFC 7698 given in Section 1 of that document. I think it
needs a definition. Further, I am not sure what the phrase 'addressing layer
0 aspects of transponders' actually applies to. Is this something which ought
to be said at the beginning about the scope of the whole document. i.e., that
it addresses just the layer 0 aspects of all components mentioned? Please
clarify.
s2.6, para 3: The etc at the end of this paragraph leaves one hanging without
complete knowledge of what properties are covered. Will I find out how it is
completed later? If so some pointers to sections where the complete lists can
be seen would be useful.
s2.6.1, para 1: Expand SDO on first use (not deemed to be well-known).
s2.6.1, para 1: s/to consider other/consideration of other/, s/will be
available/might be available/
s2.6.1, para 1: It might be worth repeating the definition of "Transversely
compatible dense wavelength division multiplexing" (DWDM) i.e., that it is a
standard that ensures DWDM equipment from different vendors can work together
in a network.
s2.6.1, para 2, last sentence: s/as transceiver capability/as a transceiver
capability/
s2.6.2, 1st bullet: Expand FEC.
s2.6.3, para 1: s/allows to encode, explicitly,/allows the encoding,
explicitly, of/
s2.6.4, para 4: s/allows to describe/allows the description of/
s2.7, para 6 (just before Figure 7): s/as the transmitter/than the transmitter/
s2.7, para 7: s/the capability whether/the capability that/
s2.10, para 4: s/ Section 4 intend/Section 4 intends/
s2.10, Figures 9 and 10: What is the significance of the term 'Colored OT'?
Is this known from some other context?
s2.11.1, para 1: s/in transmit direction/in the transmit direction/; s/in
receive direction/in the receive direction/
s2.11.1, para 3: s/as leaf list of the otsi/as a leaf list of the OTSi/
s2.11.1, para 4: s/in forward direction/in the forward direction/; s/in reverse
direction/in the reverse direction/
s2.11.1, bullet points 1-3: s/in reverse direction/in the reverse direction/ (3
places)
s2.11.1, para 11 and s2.11.1.2, para 5: s/Like/Similarly/
s2.11.1, para 11: s/in forward and reverse direction/in the forward and
reverse directions/
s2.11.1, last para: s/in following/in the following/; s/provided how
these/provided as to how these/
s2.11.1.1, para 5: s$in transmit/forward direction$in the transmit/forward
direction$; s$in receive/reverse direction$in the receive/reverse direction$
s2.11.1.1. para 7: Does the term local-link-connectivity list need a reference
to its definition which may be in draft-ietf-teas-yang-te-topo or RFC 8795?
s2.11.1.2, para 4: s$in transmit/forward direction$in the transmit/forward
direction$; s$in receive/reverse direction$in the receive/reverse direction$
s2.11.1.2 para 6: s/the protected ad-drop/the protected add-drop/
s2.11.1.1 and .2, titles of Figures 15-18: s/WDM-TE node/WDM-TE-node/
s2.11.1.3, paras 1 and 4: Do 'The difference compared to use case (i)' and 'in
the same way as for use case (i)' refer (again) to s2.11.1.1 - there doesn't
seem to be any usage of (i) as a bullet label around here.
s2.11.2.1, para 1: Missing closing bracket after 'TE-link ("te-link-attributes"'
s3 in 'grouping amplifier-params: container operational: leaf type-variety'
s/This attributes/This attribute/
s3 in 'grouping oms-element: elt-index': s/allowing to sort/allowing the
sorting/
s3 in 'container transponders: list transponder:leaf
termination-type-capabilities: enum 3r-or-tunnel:" s/can be configure/can be
configured/
s3 in 'container transponders:list transceiver:leaf
explicit-transceiver-mode-ref:" s/The refernce to the explicit/The reference to
the explicit/
s3 in 'container transponders:container regen-groups:leaf regen-metric:'
s/among different group/among different groups/
s3 in 'container transponders:container regen-groups:leaf-list
transponder-ref:' s/The list of transponder/The list of transponders/
Appendix B: There does not appear to be a reference to Appendix B in the body
of the document. I would have expected that there would have been a pointer to
it somewhere!
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
