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!
--
*
Dieter Beller*
Open Agent & Routing Project Manager
Network Infrastructure - Optical Networks Division
Contact number: +49 175 7266874 | Teams Chat
<https://teams.microsoft.com/l/chat/0/[email protected]>
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.
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
