Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review

[Zhenghaomian <[e-mail]>]

Hi Qilei, All,

Thank you for the discussion and the resolution. I'm writing to approve the publication as a part of procedure.




________________________________

郑好棉 Zheng Haomian
Mobile: [phone]
Email: [e-mail]

发件人：wang.qilei <[e-mail]>
收件人：rvanrheenen <[e-mail]>;rvaliveti <[e-mail]>;Zhenghaomian <[e-mail]>;huubatwork <[e-mail]>;sergio.belotti <[e-mail]>
抄 送：rfc-editor <[e-mail]>;ccamp-ads <[e-mail]>;ccamp-chairs <[e-mail]>;adrian <[e-mail]>;jgs <[e-mail]>;auth48archive <[e-mail]>;Fatai Zhang <[e-mail]>;andrew-ietf <[e-mail]>
时 间：2023-03-20 09:56:01
主 题：Re: AUTH48: RFC-to-be 9376 for your review


Hi RFC editor,


Thanks for your work. I reviewed the draft again and have no more changes.

To the other authors, please let us know whether you have further comments, if no, please let us know whether you support the publication of the draft.


Thanks

Qilei



Original
From: RebeccaVanRheenen <[e-mail]>
To: 王其磊10101413;Radhakrishna Valiveti <[e-mail]>;Zhenghaomian <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Cc: RFC Editor <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Adrian Farrel <[e-mail]>;John Scudder <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2023年03月16日 02:54
Subject: Re: AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review
Hi Qilei,

We updated to use "Gbit/s” rather than “G” as requested. The updated files are listed below. Please take a look and let us know if any further changes would be helpful. Note that the change to "Gbit/s” was also made in the document title.

Updated XML file:
  https://www.rfc-editor.org/authors/rfc9376.xml

Updated output files:
  https://www.rfc-editor.org/authors/rfc9376.txt
  https://www.rfc-editor.org/authors/rfc9376.pdf
  https://www.rfc-editor.org/authors/rfc9376.html

Diff file showing all changes made during AUTH48:
  https://www.rfc-editor.org/authors/rfc9376-auth48diff.html

Diff files showing all changes:
  https://www.rfc-editor.org/authors/rfc9376-diff.html
  https://www.rfc-editor.org/authors/rfc9376-rfcdiff.html (side-by-side diff)
  https://www.rfc-editor.org/authors/rfc9376-alt-diff.html (diff showing changes where text moved/deleted)

AUTH48 status of this document:
  https://www.rfc-editor.org/auth48/rfc9376X

Thank you,
RFC Editor/rv



> On Mar 14, 2023, at 6:57 PM, [e-mail] wrote:
>
> Hi RFC editor,
>
>
>
> Thanks for your comments.
>
> I reviewed the draft again, and believe we should use "Gbit/s" consisently in this draft to avoid confusion, please replace all the "100G" / "1.25G" / "10G" / "10.3G" / "40G" / "2.5G" with "100Gbit/s" / "1.25Gbit/s" / "10Gbit/s" / "10.3Gbit/s" / "40Gbit/s" / "2.5Gbit/s".
>
>
>
> Any other questions, please let us know.
>
>
>
> Thanks
>
> Qilei
>
>
>
>
>
>
>
> Original
> From: RebeccaVanRheenen <[e-mail]>
> To: 王其磊10101413;[e-mail] <[e-mail]>;Zhenghaomian <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> Cc: RFC Editor <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Adrian Farrel <[e-mail]>;John Scudder <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> Date: 2023年03月15日 01:30
> Subject: Re: AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review
> Hello Qilei,
>
> Thank you for the quick response! We have updated the document and have one final question:
>
> >> For our understanding, what is the rationale for using different notation for these two cases (for example)?
> >>
> >> Section 1: a nominal rate of n * 100 Gbit/s
> >> vs.
> >> Section 2: the bitrate is approximately n*100G
> >
> > Qilei: great. I even did not notice that.
> >
> > To be consistent, please replace all the n100G with n*100Gbit/s.
>
> We updated as you requested. Is the rationale here to use "Gbit/s" consistently in mathematical expressions (e.g., “n*100 Gbit/s”) and use “G” with numerals (e.g., “100G” and “1.25G")? Please review and let us know if any further updates are needed for consistency and clarity.
>
> _______________
>
> Updated XML file:
>   https://www.rfc-editor.org/authors/rfc9376.xml
>
> Updated output files:
>   https://www.rfc-editor.org/authors/rfc9376.txt
>   https://www.rfc-editor.org/authors/rfc9376.pdf
>   https://www.rfc-editor.org/authors/rfc9376.html
>
> Diff file showing all changes made during AUTH48:
>   https://www.rfc-editor.org/authors/rfc9376-auth48diff.html
>
> Diff files showing all changes:
>   https://www.rfc-editor.org/authors/rfc9376-diff.html
>   https://www.rfc-editor.org/authors/rfc9376-rfcdiff.html (side-by-side diff)
>   https://www.rfc-editor.org/authors/rfc9376-alt-diff.html (diff showing changes where text moved/deleted)
>
> AUTH48 status of this document:
>  https://www.rfc-editor.org/auth48/rfc9376X
>
> Thank you,
> RFC Editor/rv
>
>
>
> > On Mar 13, 2023, at 6:34 PM, [e-mail] wrote:
> >
> > Hi RFC editor,
> >
> >
> >
> > Thank you for your prompt processing, please see my replies in-line start with "Qilei: ".
> >
> >
> >
> > Thanks
> >
> > Qilei
> >
> >
> >
> >
> >
> >
> >
> > Original
> > From: RebeccaVanRheenen <[e-mail]>
> > To: 王其磊10101413;[e-mail] <[e-mail]>;Zhenghaomian <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> > Cc: RFC Editor <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Adrian Farrel <[e-mail]>;John Scudder <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> > Date: 2023年03月14日 07:58
> > Subject: Re: AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review
> > Hello Qilei,
> >
> > Thank you for responding to our questions. We updated the document accordingly and noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9376).
> >
> > We have a few followup questions:
> >
> > >> 15) <!-- [rfced] Please review "not to transmit". Should this read "and not
> > >> transmit", "so that it will not transmit", or something similar?
> > >>
> > >> Original:
> > >>   If the total rate of the ODUk LSPs planned to be
> > >>   carried over an ODUCn link is smaller than n*100G, it is possible to
> > >>   "crunch" the OTUCn not to transmit the unused tributary slots.
> > >> -->
> > >>
> > >
> > > 15),
> > >
> > > Section 3.1.1
> > >
> > > OLD:
> > >    If the total rate of the ODUk LSPs planned to be
> > >    carried over an ODUCn link is smaller than n*100G, it is possible to
> > >    "crunch" the OTUCn not to transmit the unused tributary slots.
> > >
> > > NEW:
> > >    If the total rate of the ODUk LSPs planned to be
> > >    carried over an ODUCn link is smaller than n*100G, it is possible to
> > >     "crunch" the OTUCn and thus the unused tributary slots are not
> > >     transmitted.
> >
> > We have updated as you suggest above. May we further revise "and thus” in one of the following ways to improve the grammar of the sentence?
> >
> > Perhaps (“thus” moved to follow “are”):
> >    If the total rate of the ODUk LSPs planned to be
> >    carried over an ODUCn link is smaller than n*100G, it is possible to
> >    "crunch" the OTUCn, and the unused tributary slots are thus not
> >    transmitted.
> >
> > Or:
> >    If the total rate of the ODUk LSPs planned to be
> >    carried over an ODUCn link is smaller than n*100G, it is possible to
> >    "crunch" the OTUCn; thus, the unused tributary slots are not
> >    transmitted.
> >
> >
> >
> >
> > Qilei: the first one is accepted.
> >
> > "   If the total rate of the ODUk LSPs planned to be
> >    carried over an ODUCn link is smaller than n*100G, it is possible to
> >    "crunch" the OTUCn, and the unused tributary slots are thus not
> >    transmitted."
> >
> >
> >
> >
> >
> >
> >
> >
> > >> 21) <!-- [rfced] We are having trouble understanding how the text starting with
> > >> "the label..." connects to the rest of the sentence. Should this be a new
> > >> sentence?
> > >>
> > >> Original:
> > >>   As the resource on the ODUCn link which can be seen by the client
> > >>   ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in
> > >>   [RFC7139] is able to accommodate the requirement of the setup of
> > >>   ODUk/ODUflex over ODUCn link.
> > >>
> > >> Perhaps:
> > >>   As the resource on the ODUCn link that can be seen by the client,
> > >>   ODUk/ODUflex is a set of 5 Gbit/s slots. The label defined in
> > >>   [RFC7139] is able to accommodate the requirement of the setup of
> > >>   ODUk/ODUflex over ODUCn link.
> > >> -->
> > >>
> > >
> > > 21),
> > > Section 4.2,
> > >
> > > OLD:
> > >    As the resource on the ODUCn link which can be seen by the client
> > >    ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in
> > >    [RFC7139] is able to accommodate the requirement of the setup of
> > >    ODUk/ODUflex over ODUCn link.
> > >
> > > NEW:
> > >    As the resource on the ODUCn link that can be seen by the ODUk/ODUflex
> > >    client signal is a set of 5 Gbit/s slots, the label defined in
> > >    [RFC7139] is able to accommodate the requirement of the
> > >    setup of ODUk/ODUflex client signal over ODUCn link.
> >
> > We have updated as you suggest above, but we also added the article “an” before "ODUk/ODUflex client signal” and "ODUCn link”. Let us know if this is acceptable or if “the” is more appropriate here.
> >
> > Current:
> >    As the resource on the ODUCn link that can be seen by the ODUk/ODUflex
> >    client signal is a set of 5 Gbit/s slots, the label defined in
> >    [RFC7139] is able to accommodate the requirement of the
> >    setup of an ODUk/ODUflex client signal over an ODUCn link.
> >
> > Qilei: thanks, you are correct.
> >
> >
> >
> >
> >
> >
> >
> >
> > >> 24) <!-- [rfced] The text beginning with "Because" is not a complete
> > >> sentence. Should it be connected to the sentence that precedes it or
> > >> recast as a complete sentence?
> > >>
> > >> Original:
> > >>   For routing, it is deemed that no extension to current mechanisms
> > >>   defined in [RFC7138] is needed.  Because, once an ODUCn link is up,
> > >>   the resources that need to be advertised are the resources that are
> > >>   exposed by this ODUCn link and the multiplexing hierarchy on this
> > >>   link.
> > >>
> > >> Perhaps (connected to sentence before):
> > >>   For routing, it is deemed that no extension to current mechanisms
> > >>   defined in [RFC7138] is needed, because once an ODUCn link is up,
> > >>   the resources that need to be advertised are the resources that are
> > >>   exposed by this ODUCn link and the multiplexing hierarchy on this
> > >>   link.
> > >>
> > >> Or (recast as complete sentence):
> > >>   For routing, it is deemed that no extension to current mechanisms
> > >>   defined in [RFC7138] is needed.  Once an ODUCn link is up,
> > >>   the resources that need to be advertised are the resources that are
> > >>   exposed by this ODUCn link and the multiplexing hierarchy on this
> > >>   link.
> > >> -->
> > >>
> > >
> > > 24),
> > > Qilei: Please be noted that some updates to the texts in section 4.3 were agreed by the authors, chairs of CCAMP and AD. CCAMP chair sent one email to <[e-mail]>, explaning the cause and effect of this updates.
> > >
> > > Section 4.3
> > > OLD:
> > >     For routing, it is deemed that no extension to current mechanisms
> > >    defined in [RFC7138] is needed.  Because once an ODUCn link is up,
> > >    the resources that need to be advertised are the resources that are
> > >    exposed by this ODUCn link and the multiplexing hierarchy on this
> > >    link.  Since the ODUCn link is the lowest layer of the ODU
> > >    multiplexing hierarchy involving multiple ODU layers, and there is a
> > >    1:1 correspondence with the OTUCn signal, there is no need to
> > >    explicitly define a new value to represent the ODUCn signal type in
> > >    the OSPF-TE routing protocol.
> > >
> > >    The OSPF-TE extension defined in section 4 of [RFC7138] can be reused
> > >    to advertise the resource information on the ODUCn link to help
> > >    finish the setup of ODUk/ODUflex.
> > >
> > > NEW:
> > >     For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed.
> > >
> > >     The ODUCn link, which is the lowest layer of the ODU multiplexing hierarchy involving multiple ODU layers, is assumed to have been already configured when GMPLS is used to set up ODUk over ODUCn, therefore the resources that need to be advertised are the resources that are exposed by this ODUCn link and the ODUk multiplexing hierarchy on it. The 5Gbit/s OPUCn time slots do not need to be advertised, while the 1.25Gbit/s and 2.5Gbit/s OPUk time slots need to be advertised using the mechanisms already defined in [RFC7138].
> > >
> > >     Since there is a 1:1 correspondence between the ODUCn and the OTUCn signal, there is no need to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing protocol.
> >
> > Thank you for providing this updated text. Should the last paragraph in the OLD above be retained or removed?
> >
> > Last paragraph in Section 4.3:
> >    The OSPF-TE extension defined in section 4 of [RFC7138] can be reused
> >    to advertise the resource information on the ODUCn link to help
> >    finish the setup of ODUk/ODUflex.
> >
> > From the OLD/NEW above, it looks like it should be removed, but we would like to confirm.
> >
> > Note that the changes here are “above editorial”, so we will ask for AD approval once you confirm how to handle that last paragraph.
> >
> >
> >
> > Qilei: the last paragraph in the OLD should be removed.
> >
> >
> >
> >
> >
> > >> c) Please review "OTN network" and let us know if any changes are needed. We
> > >> ask because the expanded form would be "Optical Transport Network network".
> > >>
> > >
> > >     c), please remove the "network" following the "OTN"
> >
> > FYI: There were some instances of “OTN networks” (plural). We removed “networks” but left “OTN” rather than using “OTNs” (with “s”) per your reply to our question #1. Please confirm that these instances are all acceptable.
> >
> >
> >
> > Qilei: "OTN" should be fine instead of "OTNs". The changes are acceptable.
> >
> >
> >
> > >> b) Both "Gbit/s" and "G" are used for units (e.g., "100 Gbit/s" and
> > >> "100G") in this document. Would you like to add text that "G"
> > >> stands for "Gbit/s", or will it be sufficiently clear to the reader?
> > >
> > >    b), it is clear, no change
> >
> > >> c) Similarly, would you like to add text that "GE" stands for
> > >> "Gigabit Ethernet"? If so, please provide the text and the location.
> > >>
> > >> Section 2:
> > >>  ITU-T defines specific ODUflex containers that are required to
> > >>  transport specific clients such as 50GE, 200GE, 400GE, etc.
> > >> -->
> > >
> > >    c),  no need to explain GE
> >
> > For our understanding, what is the rationale for using different notation for these two cases (for example)?
> >
> > Section 1: a nominal rate of n * 100 Gbit/s
> > vs.
> > Section 2: the bitrate is approximately n*100G
> >
> >
> >
> >
> >
> > Qilei: great. I even did not notice that.
> >
> > To be consistent, please replace all the n*100G with n*100Gbit/s.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ——————————
> >
> > Updated XML file:
> >    https://www.rfc-editor.org/authors/rfc9376.xml
> >
> > Updated output files:
> >    https://www.rfc-editor.org/authors/rfc9376.txt
> >    https://www.rfc-editor.org/authors/rfc9376.pdf
> >    https://www.rfc-editor.org/authors/rfc9376.html
> >
> > Diff file showing all changes made during AUTH48:
> >    https://www.rfc-editor.org/authors/rfc9376-auth48diff.html
> >
> > Diff files showing all changes:
> >    https://www.rfc-editor.org/authors/rfc9376-diff.html
> >    https://www.rfc-editor.org/authors/rfc9376-rfcdiff.html (side-by-side diff)
> >    https://www.rfc-editor.org/authors/rfc9376-alt-diff.html (diff showing changes where text moved/deleted)
> >
> > AUTH48 status of this document:
> >   https://www.rfc-editor.org/auth48/rfc9376X
> >
> > Thank you,
> > RFC Editor/rv
> >
> >
> >
> >
> >
> > > On Mar 9, 2023, at 6:23 PM, [e-mail] wrote:
> > >
> > > Resend,,,,
> > >
> > > since I received a number of undelivered email notification for Adrian, Fatai and Andrew.
> > >
> > >
> > >
> > > ==========================================================
> > >
> > >
> > >
> > > Dear RFC editor,
> > >
> > >
> > >
> > > First, I approve this RFC for publication.
> > >
> > > Second, replies to the comments could be seen below, which are from Huub and myself. The numbering below is consistent with the comments proposed by the RFC editor.
> > >
> > >
> > >
> > > 1),
> > > Title
> > >
> > > OLD:
> > > Applicability of GMPLS for Beyond 100G Optical Transport Network
> > >
> > > NEW:
> > > Applicability of GMPLS for beyond 100G Optical Transport Network
> > >
> > > Qilei: Usage of "Optical Transport Networks" is not supported since G.709 use "Optical Transport Network",   network instead of networks.
> > > Fine with other changes proposed by the RFC editor.
> > >
> > > 2),
> > > Qilei: No need to include the "100G" and "Optical Transport Network" in the abstract, since "100G" and "Optical Transport Network" could be inferred.
> > >
> > > 3),
> > > Qilei: I got feedback from Huub, he was OK for: a) H. van Helvoort and b) Hai Gaoming BV.
> > >
> > > 4),
> > > "B100G OTN"
> > >
> > > 5),
> > >
> > > Section 1
> > >
> > > OLD:
> > > Because [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts with [ITU-T_G709_2020] by first presenting an overview of the OTUCn and ODUCn signals, and then analyzing how the current GMPLS routing and signalling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links.
> > >
> > > NEW:
> > > Since [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared to [ITU-T_G709_2016], this document first presents an overview of the OTUCn and ODUCn signals in [ITU-T_G709_2020], and then analyzing how the current GMPLS routing and signalling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links.
> > >
> > > 6),
> > > Qilei: Yes
> > >
> > > 7),
> > > Section 2
> > >
> > > OLD:
> > >    FlexO:  Flexible OTN information structure.  This information
> > >       structure is usually with a specific bit rate and frame format,
> > >       consisting of overhead and payload, which is used as a group for
> > >       the transport of an OTUCn signal.
> > >
> > > NEW:
> > >  FlexO:  Flexible OTN information structure.  This information
> > >       structure usually has a specific bitrate and frame format
> > >       that consists of overhead and payload, which are used as a group for
> > >       the transport of an OTUCn signal.
> > >
> > > 8),
> > > Section 2
> > >
> > > OLD:
> > >  ITU-T defines specific ODUflex containers that are required to
> > >    transport specific clients such as 50GE, 200GE, 400GE, etc.
> > > ...
> > >
> > > NEW:
> > >  [ITU-T_G709_2020] defines specific ODUflex containers that are required to
> > >    transport specific clients such as 50GE, 200GE, 400GE, etc.
> > > ...
> > > [ITU-T_G709_2020] supports the notion of a reduced rate OTUCn signal, termed the OTUCn-M.
> > >
> > > 9),
> > > Qilei: OK with the update proposed by RFC editor.
> > >
> > > 10),
> > > Qilei: yes, it should be Figure 11-4.
> > >
> > > 11),
> > > Section 2
> > >
> > > OLD:
> > >       Specifically, the payload area consists of M 5 Gbit/s tributary
> > >       slots - where M is less than 20*n, which is the number of
> > >       tributary slots in the OTUCn signal.
> > >
> > > NEW:
> > >       Specifically, the payload area consists of M tributary
> > >       slots (each 5 Gbit/s), where M is less than 20*n, which
> > >       is the number of tributary slots in the OTUCn signal.
> > >
> > >
> > > Section 4.2
> > >
> > > OLD:
> > >    One ODUC10
> > >    has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4.
> > >
> > > NEW:
> > >    One ODUC10
> > >      has 200 slots (each 5 Gbit/s), and twenty of them are
> > >      allocated to the ODU4.
> > >
> > >
> > > Section 3.4:
> > >
> > > OLD:
> > >    As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary
> > >    slots (TSs).
> > >
> > > NEW:
> > >    As mentioned above, the OPUCn signal has 20*n tributary
> > >      slots (TSs) (each 5 Gbit/s).
> > >
> > >
> > > 12),
> > >
> > > Qilei: OK
> > >
> > > Section 2:
> > >
> > > OLD:
> > >    PSI:  OPU Payload Structure Indicator.  This is a 256-byte signal
> > >       that describes the composition of the OPU signal.
> > >
> > > NEW:
> > >    PSI:  Payload Structure Indicator.  This is a 256-byte signal
> > >       that describes the composition of the OPU signal.
> > >
> > > 13),
> > >
> > > Qilei: OK
> > >
> > > Section 2
> > >
> > > OLD:
> > >   Detailed descriptions of these terms can be found in
> > >    [ITU-T_G709_2020].
> > >
> > > NEW:
> > >    Detailed descriptions for some of these terms can be found in
> > >    [ITU-T_G709_2020].
> > >
> > > 14),
> > > Qilei: OK.
> > >
> > > Section 3.1:
> > >
> > > OLD:
> > >    *  The OTUCn signals can be viewed as being formed by interleaving n
> > >       synchronous OTUC signals (which are labeled 1, 2, ..., n).
> > >
> > > NEW:
> > >    *  The OTUCn signals are formed by interleaving n
> > >       synchronous OTUC signals (which are labeled 1, 2, ..., n).
> > >
> > > 15),
> > >
> > > Section 3.1.1
> > >
> > > OLD:
> > >    If the total rate of the ODUk LSPs planned to be
> > >    carried over an ODUCn link is smaller than n*100G, it is possible to
> > >    "crunch" the OTUCn not to transmit the unused tributary slots.
> > >
> > > NEW:
> > >    If the total rate of the ODUk LSPs planned to be
> > >    carried over an ODUCn link is smaller than n*100G, it is possible to
> > >     "crunch" the OTUCn and thus the unused tributary slots are not
> > >     transmitted.
> > >
> > > 16),
> > >
> > > Section 3.2
> > >
> > > OLD:
> > >    The ODUC frames have the same structure as a standard ODU
> > >    in the sense that it has the same overhead and payload areas, but has
> > >    a higher rate since its payload area can embed an ODU4 signal.
> > >
> > > NEW:
> > >    The ODUC frames have the same structure as a standard ODU
> > >    in the sense that the frames have the same overhead and payload
> > >    areas but have a higher rate since their payload area can embed
> > >    an ODU4 signal.
> > >
> > > 17),
> > >
> > > Section 3.4
> > >
> > > OLD:
> > >    *  The TS availability bit indicates if the tributary slot is
> > >       available or unavailable
> > >
> > >    *  The TS occupation bit indicates if the tributary slot is allocated
> > >       or unallocated
> > >
> > >    *  The tributary port number (14 bits) of the client signal that is
> > >       being carried in this specific TS.  A flexible assignment of
> > >       tributary port to tributary slots is possible.  Numbering of
> > >       tributary ports is from 1 to 10*n.
> > >
> > > NEW:
> > >    *  The TS availability bit indicates if the tributary slot is
> > >       available or unavailable.
> > >
> > >    *  The TS occupation bit indicates if the tributary slot is allocated
> > >       or unallocated.
> > >
> > >    *  The tributary port number (14 bits) indicates the port number of the
> > >       client signal that is
> > >       being carried in this specific TS.  A flexible assignment of
> > >       tributary port to tributary slots is possible.  Numbering of
> > >       tributary ports is from 1 to 10*n.
> > >
> > > 18),
> > > Qilei: the figure number is correct. No modification is needed.
> > >
> > > 19),
> > >
> > > Section 4.2, 4.3
> > >
> > > OLD:
> > >    4.  GMPLS Implications and Applicability
> > >      4.1.  TE-Link Representation
> > >      4.2.  Implications and Applicability for GMPLS Signalling
> > >      4.3.  Implications and Applicability for GMPLS Routing
> > >
> > > NEW:
> > >    4.  GMPLS Implications and Applicability
> > >      4.1.  TE-Link Representation
> > >      4.2.  GMPLS Signaling
> > >      4.3.  GMPLS Routing
> > >
> > > 20),
> > >
> > > Figure 4, Figure 5
> > >
> > > OLD:
> > >    Figure 4: OTUCn TE-Links
> > >    Figure 5: Multiple-hop ODUCn TE-Link
> > >
> > > NEW:
> > >    Figure 4: One-Hop OTUCn TE-Link
> > >    Figure 5: Multi-Hop ODUCn TE-Link
> > >
> > > 21),
> > > Section 4.2,
> > >
> > > OLD:
> > >    As the resource on the ODUCn link which can be seen by the client
> > >    ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in
> > >    [RFC7139] is able to accommodate the requirement of the setup of
> > >    ODUk/ODUflex over ODUCn link.
> > >
> > > NEW:
> > >    As the resource on the ODUCn link that can be seen by the ODUk/ODUflex
> > >    client signal is a set of 5 Gbit/s slots, the label defined in
> > >    [RFC7139] is able to accommodate the requirement of the
> > >    setup of ODUk/ODUflex client signal over ODUCn link.
> > >
> > > 22),
> > >
> > > Section 4.2
> > >
> > > OLD:
> > >    Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14
> > >    bits, while this field in [RFC7139] only has 12 bits, some extension
> > >    work will eventually be needed.
> > >
> > > NEW:
> > >    Since the TPN defined in [ITU-T_G709_2020] (where it is referred to as
> > >    "tributary port #") for an ODUCn link has 14 bits, while this field in
> > >    [RFC7139] only has 12 bits, some extension work will eventually be needed.
> > >
> > > 23),
> > >
> > > Section 4.2,
> > >
> > > OLD:
> > >    With this label encoding, only 20 out of the 200 bits mask are non-
> > >    zero, and is very inefficient.
> > >
> > > NEW:
> > >    With this label encoding, only 20 out of the 200 bits mask are non-
> > >    zero, which is very inefficient.
> > >
> > > 24),
> > > Qilei: Please be noted that some updates to the texts in section 4.3 were agreed by the authors, chairs of CCAMP and AD. CCAMP chair sent one email to <[e-mail]>, explaning the cause and effect of this updates.
> > >
> > > Section 4.3
> > > OLD:
> > >     For routing, it is deemed that no extension to current mechanisms
> > >    defined in [RFC7138] is needed.  Because once an ODUCn link is up,
> > >    the resources that need to be advertised are the resources that are
> > >    exposed by this ODUCn link and the multiplexing hierarchy on this
> > >    link.  Since the ODUCn link is the lowest layer of the ODU
> > >    multiplexing hierarchy involving multiple ODU layers, and there is a
> > >    1:1 correspondence with the OTUCn signal, there is no need to
> > >    explicitly define a new value to represent the ODUCn signal type in
> > >    the OSPF-TE routing protocol.
> > >
> > >    The OSPF-TE extension defined in section 4 of [RFC7138] can be reused
> > >    to advertise the resource information on the ODUCn link to help
> > >    finish the setup of ODUk/ODUflex.
> > >
> > > NEW:
> > >
> > >     For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed.
> > >
> > >     The ODUCn link, which is the lowest layer of the ODU multiplexing hierarchy involving multiple ODU layers, is assumed to have been already configured when GMPLS is used to set up ODUk over ODUCn, therefore the resources that need to be advertised are the resources that are exposed by this ODUCn link and the ODUk multiplexing hierarchy on it. The 5Gbit/s OPUCn time slots do not need to be advertised, while the 1.25Gbit/s and 2.5Gbit/s OPUk time slots need to be advertised using the mechanisms already defined in [RFC7138].
> > >
> > >     Since there is a 1:1 correspondence between the ODUCn and the OTUCn signal, there is no need to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing protocol.
> > >
> > > 25),
> > > Qilei: OK
> > >
> > > OLD:
> > >    [ITU-T_G709_2020]
> > >               ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
> > >               06/2020", June 2020.
> > >
> > >    [ITU-T_G709_2012]
> > >               ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
> > >               02/2012", February 2012.
> > >
> > >    [ITU-T_G709_2016]
> > >               ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
> > >               07/2016", July 2016.
> > >
> > > NEW:
> > >    [ITU-T_G709_2020]
> > >               ITU-T, "Interfaces for the optical transport network",
> > >               ITU-T Recommendation G.709, June 2020.
> > >
> > >    [ITU-T_G709_2012]
> > >               ITU-T, "Interfaces for the optical transport network",
> > >               ITU-T Recommendation G.709, February 2012.
> > >
> > >    [ITU-T_G709_2016]
> > >               ITU-T, "Interfaces for the optical transport network",
> > >               ITU-T Recommendation G.709, June 2016.
> > >
> > > 26),
> > > Qilei:
> > >     a), use "n * 100Gbit/s".
> > >     b), it is clear, no change
> > >     c),  no need to explain GE
> > >
> > >
> > > 27),
> > > Qilei: the following terminologies are suggested:
> > >     a),
> > >     TE link
> > >     section-layer
> > >     multi-hop
> > >
> > >     b),
> > >     ODUflex
> > >     bitrate
> > >
> > >     c), please remove the "network" following the "OTN"
> > >
> > >     d), "k" and "j" stand for the high order and lower order of ODU, which are known to people who are familar with OTN, suggest no change to the draft.
> > >
> > >     e), correct
> > >
> > >     f), Generalized Payload Identifier, in RFC3471.
> > >
> > > 28),
> > > Qilei: done
> > >
> > > Thank you
> > >
> > > Qilei
> > >
> > >
> > >
> > >
> > >
> > > Original
> > > From: [e-mail] <[e-mail]>
> > > To: 王其磊10101413;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> > > Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> > > Date: 2023年02月28日 14:40
> > > Subject: Re: AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review
> > > Authors,
> > >
> > > While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> > >
> > > 1) <!-- [rfced] Please review "for Beyond 100G Optical Transport Network" in the
> > > document title. Would any updates be helpful to improve clarity?
> > >
> > > Original:
> > >    Applicability of GMPLS for Beyond 100G Optical Transport Network
> > >
> > > Perhaps:
> > >    Applicability of GMPLS for beyond 100G Optical Transport Networks
> > >
> > > Or:
> > >    Applicability of GMPLS for Optical Transport Networks with
> > >                    Link Capacity above 100G
> > >
> > >
> > > In addition, please review the short title (which appears in the running header
> > > at the top of each page in the PDF output). For now, we have updated as shown
> > > below to align better with the document title, but changes may be needed
> > > depending on the response to the question above about the document title.
> > >
> > > Original:
> > >    B100G Extensions
> > >
> > > Perhaps:
> > >    Applicability of GMPLS beyond 100G OTN
> > > -->
> > >
> > >
> > > 2) <!-- [rfced] We note that the document title includes "100G" and
> > > "Optical Transport Network", but these terms are not included in the
> > > abstract. Let us know if any updates are needed.
> > > -->
> > >
> > >
> > > 3) <!-- [rfced] Huub, we made the following updates in your author listing.
> > > Please let us know any concerns.
> > >
> > > a) We updated your surname in the document header from "H. Helvoort"
> > > to "H. van Helvoort".
> > >
> > > b) We updated "Hai Gaoming B.V" to "Hai Gaoming BV" (no period) per the
> > > affiliation listed in RFCs 8234, 8227, and 7771. Please let us know if
> > > "Hai Gaoming B.V." (two periods) is better.
> > > -->
> > >
> > >
> > > 4) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> > > title) for use on https://www.rfc-editor.org/search. -->
> > >
> > >
> > > 5) <!-- [rfced] What does "this document starts with [ITU-T_G709_2020]" mean
> > > here? Will it be clear to readers?
> > >
> > > Original:
> > >    Because [ITU-T_G709_2020] does not introduce any new features to
> > >    OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts
> > >    with [ITU-T_G709_2020] by first presenting an overview of the OTUCn
> > >    and ODUCn signals, and then analyzing how the current GMPLS routing
> > >    and signalling mechanisms can be utilized to set up ODUk (e.g.,
> > >    ODUflex) LSPs over ODUCn links.
> > > -->
> > >
> > >
> > > 6) <!-- [rfced] Would you like to put the terms listed and defined in Section 2
> > > in alphabetical order?
> > > -->
> > >
> > >
> > > 7) <!-- [rfced] Please review "is usually with a specific bit rate and frame
> > > format". Should this read "usually has a specific bit rate and frame
> > > format" (or something similar) for clarity? Also, what does the "which
> > > is.." clause refer to ("bit rate and frame format" or "overhead and
> > > payload")? Will this be clear to readers?
> > >
> > > Original:
> > >    FlexO:  Flexible OTN information structure.  This information
> > >       structure is usually with a specific bit rate and frame format,
> > >       consisting of overhead and payload, which is used as a group for
> > >       the transport of an OTUCn signal.
> > >
> > > Perhaps:
> > >    FlexO:  Flexible OTN information structure.  This information
> > >       structure usually has a specific bitrate and frame format
> > >       (consisting of overhead and payload), which are used as a group for
> > >       the transport of an OTUCn signal.
> > >
> > > Or:
> > >    FlexO:  Flexible OTN information structure.  This information
> > >       structure usually has a specific bitrate and frame format
> > >       that consists of overhead and payload, which are used as a group for
> > >       the transport of an OTUCn signal.
> > > -->
> > >
> > >
> > > 8) <!-- [rfced] In these sentences, would it be helpful to specify which ITU-T
> > > document "defines" and "supports"?  Or is the current text sufficient?
> > >
> > > Original:
> > >    ITU-T defines specific ODUflex containers that are required to
> > >    transport specific clients such as 50GE, 200GE, 400GE, etc.
> > >       ...
> > >    ITU-T supports the notion of a reduced rate OTUCn signal, termed the OTUCn-M.
> > > -->
> > >
> > >
> > > 9) <!-- [rfced] FYI - We removed the space before "-C" in the following
> > > definitions to correspond with the closed form used with "-Cn". In
> > > addition, we updated these definitions as follows to have a similar
> > > structure. Please review and let us know any objections.
> > >
> > > Original:
> > >    ODUC:  Optical Data Unit -C; this signal has a bandwidth of
> > >       approximately 100G, and is of a slightly higher bit rate than the
> > >       fixed rate ODU4 signal.
> > >    ...
> > >    OPUC:  Optical Payload Unit -C; with a payload of approximately 100G.
> > >    ...
> > >    OTUC:  Optical Transport Unit -C; with a bandwidth of approximately
> > >       100G.
> > >
> > > Updated:
> > >    ODUC:  Optical Data Unit-C.  This signal has a bandwidth of
> > >       approximately 100G and is of a slightly higher bitrate than the
> > >       fixed rate ODU4 signal.
> > >    ...
> > >    OPUC:  Optical Payload Unit-C.  This signal has a payload of
> > >       approximately 100G.
> > >    ...
> > >    OTUC:  Optical Transport Unit-C.  This signal has a bandwidth of
> > >       approximately 100G.
> > > -->
> > >
> > >
> > > 10) <!-- [rfced] Please confirm that "Figure 11-1" is correct here. We ask
> > > because Figure 11-1 of [ITU-T_G709_2020] is titled "OTUk frame structure",
> > > but this definition is for OTUCn. Note that Figure 11-4 is titled "OTUCn
> > > frame structure"; is that the correct figure reference here? Please see
> > > https://www.itu.int/rec/T-REC-G.709-202006-I/en.
> > >
> > > Original:
> > >    *  OTUCn: Fully standardized Optical Transport Unit-Cn.  This frame
> > >       structure is realized by extending the ODUCn signal with the OTU
> > >       layer overhead.  The structure of this signal is illustrated in
> > >       Figure 11-1 of [ITU-T_G709_2020].
> > > -->
> > >
> > >
> > > 11) <!--[rfced] May these instances of "5 Gbit/s" (immediately preceded by a
> > > variable or digits) be rephrased to improve readability?
> > > For comparison, Section 3.3 uses the phrase "20*n tributary slots
> > > (of 5 Gbit/s capacity)".
> > >
> > > Original (Section 2):
> > >       Specifically, the payload area consists of M 5 Gbit/s tributary
> > >       slots - where M is less than 20*n, which is the number of
> > >       tributary slots in the OTUCn signal.
> > >
> > > Perhaps:
> > >       Specifically, the payload area consists of M tributary
> > >       slots (each 5 Gbit/s), where M is less than 20*n, which
> > >       is the number of tributary slots in the OTUCn signal.
> > >
> > >
> > > Original (Section 4.2):
> > >    One ODUC10
> > >    has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4.
> > >
> > > Perhaps:
> > >    One ODUC10
> > >    has 200 slots that are each 5 Gbit/s, and twenty of them are
> > >    allocated to the ODU4.
> > >
> > >
> > > Original (Section 3.4):
> > >    As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary
> > >    slots (TSs).
> > >
> > > Perhaps:
> > >    As mentioned above, the OPUCn signal has 20*n tributary
> > >    slots (TSs) that are each 5 Gbit/s.
> > > -->
> > >
> > >
> > > 12) <!-- [rfced] May we update "OPU Payload Structure Indicator" to
> > > simply "Payload Structure Indicator" (no "OPU")? OPU is mentioned
> > > in the following sentence.
> > >
> > > Original:
> > >    PSI:  OPU Payload Structure Indicator.  This is a 256-byte signal
> > >       that describes the composition of the OPU signal.
> > >
> > > Perhaps:
> > >    PSI:  Payload Structure Indicator.  This is a 256-byte signal
> > >       that describes the composition of the OPU signal.
> > > -->
> > >
> > >
> > > 13) <!-- [rfced] This sentence appears at the end of Section 2. We note
> > > that "LSP" appears in the list of terms in Section 2, but we do not
> > > see it in [ITU-T_G709_2020]. Should this sentence be updated
> > > accordingly (i.e., "some of these terms")?
> > >
> > > Original:
> > >    Detailed descriptions of these terms can be found in
> > >    [ITU-T_G709_2020].
> > >
> > > Perhaps:
> > >    Detailed descriptions for some of these terms can be found in
> > >    [ITU-T_G709_2020].
> > > -->
> > >
> > >
> > > 14) <!-- [rfced] Is "can be viewed as being formed" correct? Or would updating
> > > to "are formed" work?
> > >
> > > Original:
> > >    *  The OTUCn signals can be viewed as being formed by interleaving n
> > >       synchronous OTUC signals (which are labeled 1, 2, ..., n).
> > >
> > > Perhaps:
> > >    *  The OTUCn signals are formed by interleaving n
> > >       synchronous OTUC signals (which are labeled 1, 2, ..., n).
> > > -->
> > >
> > >
> > > 15) <!-- [rfced] Please review "not to transmit". Should this read "and not
> > > transmit", "so that it will not transmit", or something similar?
> > >
> > > Original:
> > >    If the total rate of the ODUk LSPs planned to be
> > >    carried over an ODUCn link is smaller than n*100G, it is possible to
> > >    "crunch" the OTUCn not to transmit the unused tributary slots.
> > > -->
> > >
> > >
> > > 16) <!-- [rfced] Will it be clear to readers what "it" refers to here
> > > ("frames" or "structure")?
> > >
> > > Original:
> > >    The ODUC frames have the same structure as a standard ODU
> > >    in the sense that it has the same overhead and payload areas, but has
> > >    a higher rate since its payload area can embed an ODU4 signal.
> > >
> > > Perhaps:
> > >    The ODUC frames have the same structure as a standard ODU
> > >    in the sense that structure has the same overhead and payload areas but has
> > >    a higher rate since its payload area can embed an ODU4 signal.
> > >
> > > Or:
> > >    The ODUC frames have the same structure as a standard ODU
> > >    in the sense that the frames have the same overhead and payload
> > >    areas but have a higher rate since their payload area can embed
> > >    an ODU4 signal.
> > > -->
> > >
> > >
> > > 17) <!-- [rfced] The first two bullets are complete sentences, but the third
> > > bullet starts with a sentence fragment. How may we update this text so
> > > that the list has parallel structure?
> > >
> > > Original:
> > >    *  The TS availability bit indicates if the tributary slot is
> > >       available or unavailable
> > >
> > >    *  The TS occupation bit indicates if the tributary slot is allocated
> > >       or unallocated
> > >
> > >    *  The tributary port number (14 bits) of the client signal that is
> > >       being carried in this specific TS.  A flexible assignment of
> > >       tributary port to tributary slots is possible.  Numbering of
> > >       tributary ports is from 1 to 10*n.
> > >
> > > Perhaps:
> > >    *  The TS availability bit indicates if the tributary slot is
> > >       available or unavailable.
> > >
> > >    *  The TS occupation bit indicates if the tributary slot is allocated
> > >       or unallocated.
> > >
> > >    *  The tributary port number (14 bits) indicates the port number of the
> > >       client signal that is
> > >       being carried in this specific TS.  A flexible assignment of
> > >       tributary port to tributary slots is possible.  Numbering of
> > >       tributary ports is from 1 to 10*n.
> > > -->
> > >
> > >
> > > 18) <!--[rfced] Is Figure 3, which is titled "Digital Structure of OTN
> > > Interfaces (from Figure 6-1 of [ITU-T_G709_2020]", the correct figure
> > > number here?
> > >
> > > Original:
> > >       As Figure 3 illustrates, the ODUCn is also a high-
> > >       order ODU into which other ODUs can be multiplexed; the ODUCn
> > >       itself cannot be multiplexed into any higher rate ODU signal; it
> > >       is defined to be a section level signal.
> > > -->
> > >
> > >
> > > 19) <!-- [rfced] Please review this section title along with the titles of the
> > > subsections. Is it necessary to repeat "Implications and Applicability"
> > > in the titles of the subsections?
> > >
> > > Original:
> > >    4.  GMPLS Implications and Applicability
> > >      4.1.  TE-Link Representation
> > >      4.2.  Implications and Applicability for GMPLS Signalling
> > >      4.3.  Implications and Applicability for GMPLS Routing
> > >
> > > Perhaps:
> > >    4.  GMPLS Implications and Applicability
> > >      4.1.  TE-Link Representation
> > >      4.2.  GMPLS Signaling
> > >      4.3.  GMPLS Routing
> > > -->
> > >
> > >
> > > 20) <!-- [rfced] Please review the title of Figure 4. Would updating as shown
> > > below be in improvement? The sentence that appears right before the
> > > figure states, "Figure 4 below provides an illustration of a one-hop
> > > OTUCn TE link." Also, we included the title of Figure 5 below to show a
> > > comparison.
> > >
> > > Original:
> > >    Figure 4: OTUCn TE-Links
> > >    Figure 5: Multiple-hop ODUCn TE-Link
> > >
> > > Perhaps:
> > >    Figure 4: One-Hop OTUCn TE-Link
> > >    Figure 5: Multiple-Hop ODUCn TE-Link
> > > -->
> > >
> > >
> > > 21) <!-- [rfced] We are having trouble understanding how the text starting with
> > > "the label..." connects to the rest of the sentence. Should this be a new
> > > sentence?
> > >
> > > Original:
> > >    As the resource on the ODUCn link which can be seen by the client
> > >    ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in
> > >    [RFC7139] is able to accommodate the requirement of the setup of
> > >    ODUk/ODUflex over ODUCn link.
> > >
> > > Perhaps:
> > >    As the resource on the ODUCn link that can be seen by the client,
> > >    ODUk/ODUflex is a set of 5 Gbit/s slots. The label defined in
> > >    [RFC7139] is able to accommodate the requirement of the setup of
> > >    ODUk/ODUflex over ODUCn link.
> > > -->
> > >
> > >
> > > 22) <!-- [rfced] May this sentence be updated as follows? We ask
> > > because the acronym "TPN" does not appear in [ITU-T_G709_2020], though
> > > there is one instance of "tributary port number" and many instances of
> > > "tributary port #".
> > >
> > > Original:
> > >    Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14
> > >    bits, while this field in [RFC7139] only has 12 bits, some extension
> > >    work will eventually be needed.
> > >
> > > Perhaps:
> > >    Since the TPN defined in [ITU-T_G709_2020] (where it is referred to as
> > >    "tributary port #") for an ODUCn link has 14 bits, while this field in
> > >    [RFC7139] only has 12 bits, some extension work will eventually be needed.
> > > -->
> > >
> > >
> > > 23) <!-- [rfced] Please review "and is very inefficient". Should this read "which
> > > is very inefficient"?
> > >
> > > Original:
> > >    With this label encoding, only 20 out of the 200 bits mask are non-
> > >    zero, and is very inefficient.
> > >
> > > Perhaps:
> > >    With this label encoding, only 20 out of the 200 bits mask are non-
> > >    zero, which is very inefficient.
> > > -->
> > >
> > >
> > > 24) <!-- [rfced] The text beginning with "Because" is not a complete
> > > sentence. Should it be connected to the sentence that precedes it or
> > > recast as a complete sentence?
> > >
> > > Original:
> > >    For routing, it is deemed that no extension to current mechanisms
> > >    defined in [RFC7138] is needed.  Because, once an ODUCn link is up,
> > >    the resources that need to be advertised are the resources that are
> > >    exposed by this ODUCn link and the multiplexing hierarchy on this
> > >    link.
> > >
> > > Perhaps (connected to sentence before):
> > >    For routing, it is deemed that no extension to current mechanisms
> > >    defined in [RFC7138] is needed, because once an ODUCn link is up,
> > >    the resources that need to be advertised are the resources that are
> > >    exposed by this ODUCn link and the multiplexing hierarchy on this
> > >    link.
> > >
> > > Or (recast as complete sentence):
> > >    For routing, it is deemed that no extension to current mechanisms
> > >    defined in [RFC7138] is needed.  Once an ODUCn link is up,
> > >    the resources that need to be advertised are the resources that are
> > >    exposed by this ODUCn link and the multiplexing hierarchy on this
> > >    link.
> > > -->
> > >
> > >
> > > 25) <!-- [rfced] FYI - We updated the titles of these reference entries to match
> > > the titles in the following URLs. We also updated the month of the 2016
> > > version from July to June.
> > >
> > > - 2020 version: https://www.itu.int/rec/T-REC-G.709-202006-I/en
> > > - 2012 version: https://www.itu.int/rec/T-REC-G.709-201202-S/en
> > > - 2016 version: https://www.itu.int/rec/T-REC-G.709-201606-S/en
> > >
> > > Original:
> > >    [ITU-T_G709_2020]
> > >               ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
> > >               06/2020", June 2020.
> > >
> > >    [ITU-T_G709_2012]
> > >               ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
> > >               02/2012", February 2012.
> > >
> > >    [ITU-T_G709_2016]
> > >               ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
> > >               07/2016", July 2016.
> > >
> > > Updated:
> > >    [ITU-T_G709_2020]
> > >               ITU-T, "Interfaces for the optical transport network",
> > >               ITU-T Recommendation G.709, June 2020.
> > >
> > >    [ITU-T_G709_2012]
> > >               ITU-T, "Interfaces for the optical transport network",
> > >               ITU-T Recommendation G.709, February 2012.
> > >
> > >    [ITU-T_G709_2016]
> > >               ITU-T, "Interfaces for the optical transport network",
> > >               ITU-T Recommendation G.709, June 2016.
> > > -->
> > >
> > >
> > > 26) <!--[rfced] Regarding notation and units
> > >
> > > a) Typically, this document uses asterisk as the symbol for multiplication,
> > > and there's one instance of "x". May "x" be changed to "times" here
> > > in order to avoid using two different symbols for multiplication?
> > >
> > > Original: a nominal rate of n x 100 Gbit/s
> > > Perhaps:  a nominal rate of n times 100 Gbit/s
> > >
> > > (For comparison, in Section 2, "n*100G" is used.)
> > >
> > >
> > > b) Both "Gbit/s" and "G" are used for units (e.g., "100 Gbit/s" and
> > > "100G") in this document. Would you like to add text that "G"
> > > stands for "Gbit/s", or will it be sufficiently clear to the reader?
> > >
> > >
> > > c) Similarly, would you like to add text that "GE" stands for
> > > "Gigabit Ethernet"? If so, please provide the text and the location.
> > >
> > > Section 2:
> > >    ITU-T defines specific ODUflex containers that are required to
> > >    transport specific clients such as 50GE, 200GE, 400GE, etc.
> > > -->
> > >
> > >
> > > 27) <!-- [rfced] Terminology
> > >
> > > a) We note inconsistencies in the terms below throughout the text. Should
> > > these be uniform? If so, please let us know which form is preferred.
> > >
> > > TE link vs. TE Link vs. TE-link vs. TE-Link
> > >    Note: Although RFC 7138 uses "TE-Link", "TE link" is more common in the
> > >          RFC Series.
> > >
> > > digital section roles vs. digital section layer role
> > >    Note: If keeping the latter, we suggest adding a hyphen:
> > >          "digital section-layer role".
> > >
> > > multiple-hop vs. multihop
> > >    Note: The forms "multihop" and "multi-hop" are more common in the RFC Series
> > >          than "multiple-hop". However, RFC 7138 has two instances of "multiple-hop".
> > >
> > >
> > > b) We note inconsistencies in the term listed below. We chose the form on the
> > > right.  Please let us know any objections.
> > >
> > > ODUFlex vs. ODUflex
> > >    Note: RFCs 7062, 7138, and 7139, as well as [ITU-T_G709_2020] use "ODUflex".
> > >
> > > bit rate vs. bitrate
> > >
> > >
> > > c) Please review "OTN network" and let us know if any changes are needed. We
> > > ask because the expanded form would be "Optical Transport Network network".
> > >
> > >
> > > d) The following terms are mentioned in the text but not defined in Section 2
> > > or elsewhere in the document (though Section 3.5 includes an explanation of
> > > "ODUj"). Please review and let us know if/how these should be defined in
> > > Section 2 or elsewhere.
> > >
> > > OTUk (6 instances)
> > > OPUk (1 instance)
> > > ODUj (5 instances)
> > > OPUj (1 instance)
> > >
> > >
> > > e) "FEC" has been expanded as "Forward Error Correction (FEC)" to match
> > > [ITU-T_G709_2020]. Please review whether this expansion is accurate.
> > >
> > >
> > > f) How should "G-PID" be expanded in this document? As "Generalized Protocol
> > > Identifier"?
> > > -->
> > >
> > >
> > > 28) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> > > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > > and let us know if any changes are needed.
> > >
> > > Note that our script did not flag any words in particular, but this should
> > > still be reviewed as a best practice.
> > > -->
> > >
> > >
> > > Thank you.
> > >
> > > RFC Editor/rv/ar
> > >
> > >
> > > On Feb 27, 2023, [e-mail] wrote:
> > >
> > > *****IMPORTANT*****
> > >
> > > Updated 2023/02/27
> > >
> > > RFC Author(s):
> > > --------------
> > >
> > > Instructions for Completing AUTH48
> > >
> > > Your document has now entered AUTH48.  Once it has been reviewed and
> > > approved by you and all coauthors, it will be published as an RFC.
> > > If an author is no longer available, there are several remedies
> > > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> > >
> > > You and you coauthors are responsible for engaging other parties
> > > (e.g., Contributors or Working Group) as necessary before providing
> > > your approval.
> > >
> > > Planning your review
> > > ---------------------
> > >
> > > Please review the following aspects of your document:
> > >
> > > *  RFC Editor questions
> > >
> > >   Please review and resolve any questions raised by the RFC Editor
> > >   that have been included in the XML file as comments marked as
> > >   follows:
> > >
> > >   <!-- [rfced] ... -->
> > >
> > >   These questions will also be sent in a subsequent email.
> > >
> > > *  Changes submitted by coauthors
> > >
> > >   Please ensure that you review any changes submitted by your
> > >   coauthors.  We assume that if you do not speak up that you
> > >   agree to changes submitted by your coauthors.
> > >
> > > *  Content
> > >
> > >   Please review the full content of the document, as this cannot
> > >   change once the RFC is published.  Please pay particular attention to:
> > >   - IANA considerations updates (if applicable)
> > >   - contact information
> > >   - references
> > >
> > > *  Copyright notices and legends
> > >
> > >   Please review the copyright notice and legends as defined in
> > >   RFC 5378 and the Trust Legal Provisions
> > >   (TLP – https://trustee.ietf.org/license-info/).
> > >
> > > *  Semantic markup
> > >
> > >   Please review the markup in the XML file to ensure that elements of
> > >   content are correctly tagged.  For example, ensure that <sourcecode>
> > >   and <artwork> are set correctly.  See details at
> > >   <https://authors.ietf.org/rfcxml-vocabulary>.
> > >
> > > *  Formatted output
> > >
> > >   Please review the PDF, HTML, and TXT files to ensure that the
> > >   formatted output, as generated from the markup in the XML file, is
> > >   reasonable.  Please note that the TXT will have formatting
> > >   limitations compared to the PDF and HTML.
> > >
> > >
> > > Submitting changes
> > > ------------------
> > >
> > > To submit changes, please reply to this email using ‘REPLY ALL’ as all
> > > the parties CCed on this message need to see your changes. The parties
> > > include:
> > >
> > >   *  your coauthors
> > >
> > >   *  [e-mail] (the RPC team)
> > >
> > >   *  other document participants, depending on the stream (e.g.,
> > >      IETF Stream participants are your working group chairs, the
> > >      responsible ADs, and the document shepherd).
> > >
> > >   *  [e-mail], which is a new archival mailing list
> > >      to preserve AUTH48 conversations; it is not an active discussion
> > >      list:
> > >
> > >     *  More info:
> > >        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> > >
> > >     *  The archive itself:
> > >        https://mailarchive.ietf.org/arch/browse/auth48archive/
> > >
> > >     *  Note: If only absolutely necessary, you may temporarily opt out
> > >        of the archiving of messages (e.g., to discuss a sensitive matter).
> > >        If needed, please add a note at the top of the message that you
> > >        have dropped the address. When the discussion is concluded,
> > >        [e-mail] will be re-added to the CC list and
> > >        its addition will be noted at the top of the message.
> > >
> > > You may submit your changes in one of two ways:
> > >
> > > An update to the provided XML file
> > > — OR —
> > > An explicit list of changes in this format
> > >
> > > Section # (or indicate Global)
> > >
> > > OLD:
> > > old text
> > >
> > > NEW:
> > > new text
> > >
> > > You do not need to reply with both an updated XML file and an explicit
> > > list of changes, as either form is sufficient.
> > >
> > > We will ask a stream manager to review and approve any changes that seem
> > > beyond editorial in nature, e.g., addition of new text, deletion of text,
> > > and technical changes.  Information about stream managers can be found in
> > > the FAQ.  Editorial changes do not require approval from a stream manager.
> > >
> > >
> > > Approving for publication
> > > --------------------------
> > >
> > > To approve your RFC for publication, please reply to this email stating
> > > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > > as all the parties CCed on this message need to see your approval.
> > >
> > >
> > > Files
> > > -----
> > >
> > > The files are available here:
> > >   https://www.rfc-editor.org/authors/rfc9376.xml
> > >   https://www.rfc-editor.org/authors/rfc9376.html
> > >   https://www.rfc-editor.org/authors/rfc9376.pdf
> > >   https://www.rfc-editor.org/authors/rfc9376.txt
> > >
> > > Diff file of the text:
> > >   https://www.rfc-editor.org/authors/rfc9376-diff.html
> > >   https://www.rfc-editor.org/authors/rfc9376-rfcdiff.html (side by side)
> > >
> > > Diff of the XML:
> > >   https://www.rfc-editor.org/authors/rfc9376-xmldiff1.html
> > >
> > >
> > > Tracking progress
> > > -----------------
> > >
> > > The details of the AUTH48 status of your document are here:
> > >   https://www.rfc-editor.org/auth48/rfc9376
> > >
> > > Please let us know if you have any questions.
> > >
> > > Thank you for your cooperation,
> > >
> > > RFC Editor
> > >
> > > --------------------------------------
> > > RFC9376 (draft-ietf-ccamp-gmpls-otn-b100g-applicability-15)
> > >
> > > Title            : Applicability of GMPLS for Beyond 100G Optical Transport Network
> > > Author(s)        : Q. Wang, Ed., R. Valiveti, Ed., H. Zheng, Ed., H. Helvoort, S. Belotti
> > > WG Chair(s)      : Daniele Ceccarelli, Fatai Zhang, Luis M. Contreras
> > >
> > > Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> > >
> > >
> >
> >
> >
>
>