Authors, This is a friendly reminder that we have yet to hear back from some of you regarding this document’s readiness for publication.
Please review the AUTH48 status page (http://www.rfc-editor.org/auth48/rfc9730) for further information and the previous messages in this thread for pertinent communication. Thank you, RFC Editor/st > On Feb 12, 2025, at 10:30 AM, Sarah Tarrant <starr...@staff.rfc-editor.org> > wrote: > > Hi Yi, > > Thank you for your reply. We have marked your approval on the AUTH48 status > page for this document (see https://www.rfc-editor.org/auth48/rfc9730). > > We await approvals from each of the parties listed at the AUTH48 status page > prior to moving this document forward in the publication process. > > Thank you, > RFC Editor/st > >> On Feb 12, 2025, at 10:28 AM, Linyi (Yi) <yi....@huawei.com> wrote: >> >> Dear RFC editors, >> >> As one of the authors, I approve the publication of this draft. Please also >> mark my approval on the AUTH48 status page. >> Many thanks for your detailed review on the draft. >> >> B.R. >> Yi LIN >> >> HUAWEI France >> Marco Polo A2, 790 Avenue Maurice Donat, 06250 Mougins France >> http://www.huawei.com >> --------------------------------------------------------------------------------------------- >> This e-mail and its attachments contain confidential information from >> HUAWEI, which >> is intended only for the person or entity whose address is listed above. Any >> use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender >> by phone or email immediately and delete it! >> >> -----邮件原件----- >> 发件人: Sarah Tarrant <starr...@staff.rfc-editor.org> >> 发送时间: 2025年2月7日 15:02 >> 收件人: Zhenghaomian <zhenghaom...@huawei.com> >> 抄送: rfc-edi...@rfc-editor.org; xuyun...@caict.ac.cn; >> zhaoyang...@chinamobile.com; dieter.bel...@nokia.com; Linyi (Yi) >> <yi....@huawei.com>; teas-...@ietf.org; teas-cha...@ietf.org; >> vbee...@juniper.net; james.n.guich...@futurewei.com; >> auth48archive@rfc-editor.org >> 主题: Re: AUTH48: RFC-to-be 9730 >> <draft-ietf-teas-gmpls-controller-inter-work-17> for your review >> >> Hi Haomian, >> >> Thank you for your reply. We have marked your approval on the AUTH48 status >> page for this document (see https://www.rfc-editor.org/auth48/rfc9730). >> >> We will assume your assent to any further changes submitted by your >> coauthors unless we hear objection at that time. >> >> We will await approvals from each of the parties listed at the AUTH48 status >> page prior to moving this document forward in the publication process. >> >> Thank you, >> RFC Editor/st >> >>> On Feb 6, 2025, at 1:58 AM, Zhenghaomian <zhenghaom...@huawei.com> wrote: >>> >>> Dear RFC editors, >>> >>> Thank you for the work, I reviewed the changes and approve the publication. >>> >>> Best wishes, >>> Haomian >>> >>> -----邮件原件----- >>> 发件人: Sarah Tarrant <starr...@staff.rfc-editor.org> >>> 发送时间: 2025年2月6日 4:38 >>> 收件人: Zhenghaomian <zhenghaom...@huawei.com> >>> 抄送: rfc-edi...@rfc-editor.org; xuyun...@caict.ac.cn; >>> zhaoyang...@chinamobile.com; dieter.bel...@nokia.com; Linyi (Yi) >>> <yi....@huawei.com>; teas-...@ietf.org; teas-cha...@ietf.org; >>> vbee...@juniper.net; james.n.guich...@futurewei.com; >>> auth48archive@rfc-editor.org >>> 主题: Re: AUTH48: RFC-to-be 9730 >>> <draft-ietf-teas-gmpls-controller-inter-work-17> for your review >>> >>> Hi Haomian, >>> >>> Thank you for your reply. We have updated the document accordingly >>> >>> Please review the document carefully to ensure satisfaction as we do not >>> make changes once it has been published as an RFC. Contact us with any >>> further updates or with your approval of the document in its current form. >>> We will await approvals from each author prior to moving forward in the >>> publication process. >>> >>> The updated files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9730.txt >>> https://www.rfc-editor.org/authors/rfc9730.pdf >>> https://www.rfc-editor.org/authors/rfc9730.html >>> https://www.rfc-editor.org/authors/rfc9730.xml >>> >>> The relevant diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9730-diff.html (comprehensive >>> diff) https://www.rfc-editor.org/authors/rfc9730-auth48diff.html >>> (AUTH48 changes only) >>> >>> Note that it may be necessary for you to refresh your browser to view the >>> most recent version. >>> >>> For the AUTH48 status of this document, please see: >>> https://www.rfc-editor.org/auth48/rfc9730 >>> >>> Thank you, >>> RFC Editor/st >>> >>>> On Feb 5, 2025, at 3:20 AM, Zhenghaomian >>>> <zhenghaomian=40huawei....@dmarc.ietf.org> wrote: >>>> >>>> Dear RFC Editors, >>>> >>>> Just back from Chinese spring festival, thank you for the work, please see >>>> the responses inline. Could you please help integrate it into the XML? >>>> >>>> Best wishes, >>>> Haomian (on behalf of authors & contributors) >>>> >>>> -----邮件原件----- >>>> 发件人: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>> 发送时间: 2025年1月30日 7:08 >>>> 收件人: Zhenghaomian <zhenghaom...@huawei.com>; xuyun...@caict.ac.cn; >>>> zhaoyang...@chinamobile.com; dieter.bel...@nokia.com; Linyi (Yi) >>>> <yi....@huawei.com> >>>> 抄送: rfc-edi...@rfc-editor.org; teas-...@ietf.org; >>>> teas-cha...@ietf.org; vbee...@juniper.net; >>>> james.n.guich...@futurewei.com; auth48archive@rfc-editor.org >>>> 主题: Re: AUTH48: RFC-to-be 9730 >>>> <draft-ietf-teas-gmpls-controller-inter-work-17> 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 insert any keywords (beyond those that appear >>>> in the title) for use on https://www.rfc-editor.org/search. --> [Haomian] >>>> please help adding keywords: architecture, ACTN, control plane. >>>> >>>> 2) <!--[rfced] To make a 1:1 matchup between the acronyms and their >>>> expansions, may we remove "protocol" from the definitions below? >>>> >>>> Original: >>>> IS-IS Intermediate System to Intermediate System protocol >>>> ... >>>> OSPF Open Shortest Path First protocol >>>> >>>> Perhaps: >>>> IS-IS: Intermediate System to Intermediate System >>>> ... >>>> OSPF: Open Shortest Path First >>>> --> >>>> [Haomian] Yes, please remove the 'protocol'. >>>> >>>> 3) <!-- [rfced] To match Section 3.2, may we add a reference to RFC 7950 >>>> after "YANG" in the following sentence in Section 3.3? >>>> >>>> Additionally, as "/" can mean "and", "or", or "and/or", may we update the >>>> text for clarity? >>>> >>>> Current: >>>> For domain 1, the network elements were not enabled with GMPLS so >>>> the control is purely from the controller, via Network Configuration >>>> Protocol (NETCONF) [RFC6241] / YANG and/or PCE Communication Protocol >>>> (PCEP) [RFC5440]. >>>> >>>> Perhaps: >>>> For domain 1, the network elements were not enabled with GMPLS, so >>>> the control is purely from the controller, via Network Configuration >>>> Protocol >>>> (NETCONF) [RFC6241], YANG [RFC7950], and/or PCE Communication >>>> Protocol (PCEP) [RFC5440]. >>>> --> >>>> [Haomian] if we look at the figure 1, NETCONF/YANG ("/" means "and" here) >>>> is one option while PCEP is another, but the proposal text seems there are >>>> 3 options. How about following? >>>> NEW >>>> For domain 1, the network elements were not enabled with GMPLS, so >>>> the control is purely from the controller, via Network Configuration >>>> Protocol >>>> (NETCONF) [RFC6241] with YANG [RFC7950] data model, and/or PCE >>>> Communication Protocol (PCEP) [RFC5440]. >>>> >>>> 4) <!--[rfced] To clarify "label inter-domain information", may we update >>>> the text as follows? >>>> >>>> Original: >>>> Once the orchestrator(MD) has >>>> computed the E2E path, RSVP-TE or PCEP can be used in the different >>>> domains to set up the related segment tunnel consisting of label >>>> inter-domain information... >>>> >>>> Perhaps: >>>> Once the orchestrator(MD) has >>>> computed the E2E path, RSVP-TE or PCEP can be used in the different >>>> domains to set up the related segment tunnel consisting of >>>> information about inter-domain labels... >>>> --> >>>> [Haomian] Yes this is more clear. >>>> >>>> 5) <!--[rfced] In the following sentence, is the intention that any >>>> topology-related YANG module can be used? Or should a specific >>>> topology-related YANG module be cited here? >>>> >>>> Original: >>>> If the resources of inter-domain links are managed by the >>>> orchestrator(MD), each domain controller can provide to the >>>> orchestrator(MD) the list of available labels (e.g. timeslots if OTN >>>> is the scenario) using the IETF Topology YANG model and related >>>> technology specific extension. >>>> >>>> Perhaps: >>>> If the resources of inter-domain links are managed by the >>>> Orchestrator(MD), each domain controller can provide to the >>>> Orchestrator(MD) the list of available labels (e.g., time slots if >>>> the OTN is the scenario) using a topology-related YANG module and a >>>> specific technology-related extension. >>>> --> >>>> [Haomian] The YANG module to be used depends on the network switching >>>> technology, I think the proposed text this is more clear, but I prefer to >>>> make it plural. >>>> NEW: >>>> If the resources of inter-domain links are managed by the >>>> Orchestrator(MD), each domain controller can provide to the >>>> Orchestrator(MD) the list of available labels (e.g., time slots if >>>> the OTN is the scenario) using topology-related YANG modules and >>>> specific technology-related extensions. >>>> >>>> 6) <!-- [rfced] Table 1: Note that we converted the text table into >>>> <table> format. It seems the notes related to the dotted boxes (in the >>>> original text table) appear in the bulleted list after the table. We have >>>> updated the table and notes slightly to fit with the updated <table> >>>> format. >>>> Please review and let us know if any corrections are needed. >>>> >>>> In addition, may we remove "(Not applicable)" from the table header, as it >>>> seems redundant with the text that follows? >>>> >>>> Current: >>>> Single PCE (Not applicable) >>>> >>>> Perhaps: >>>> Single PCE >>>> --> >>>> [Haomian] I am good with the change. >>>> >>>> 7) <!--[rfced] To improve readability, may we update this sentence as >>>> follows? >>>> >>>> Original: >>>> These two models are still possible to be used, although they are >>>> not the main methods. >>>> >>>> Perhaps: >>>> It is still possible to use these two models, although they are not >>>> the main methods. >>>> --> >>>> [Haomian] I am good with the change. >>>> >>>> 8) <!-- [rfced] It appears that [YANG-TE] (draft-ietf-teas-yang-te) does >>>> not have a Section 3.3.2. Please review and let us know how this citation >>>> should be updated. >>>> >>>> Current: >>>> The Orchestrator(ML) is responsible to decide the creation of H-LSP >>>> in the lower-layer network if it acts as a VNTM. Then it requests >>>> the L-Controller to create the H-LSP via, for example, MPI interface >>>> under the ACTN architecture. See Section 3.3.2 of [YANG-TE]. >>>> --> >>>> [Haomian] I see [YANG-TE] removed the original 3.3.2 about "Tunnel >>>> hierarchical link endpoint", so I would propose to remove the last >>>> sentence and citation. >>>> >>>> 9) <!-- [rfced] FYI - For reference [G.808.1], we added the URL: >>>> https://www.itu.int/rec/T-REC-G.808.1-201405-I/en. Please let us know if >>>> there is any objection. >>>> >>>> Original: >>>> [G.808.1] ITU-T, "Generic protection switching - Linear trail and >>>> subnetwork protection", G.808.1, May 2014. >>>> >>>> Current: >>>> [G.808.1] ITU-T, "Generic protection switching - Linear trail and >>>> subnetwork protection", ITU-T Recommendation G.808.1, May >>>> 2014, <https://www.itu.int/rec/T-REC-G.808.1-201405-I/en>. >>>> --> >>>> [Haomian] I am good with the change. >>>> >>>> 10) <!--[rfced] FYI - We have added expansions for the following >>>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please >>>> review each expansion in the document carefully to ensure correctness. >>>> >>>> Link State Advertisement (LSA) >>>> Representational State Transfer (REST) >>>> --> >>>> [Haomian] Yes these are correct. >>>> >>>> 11) <!-- [rfced] Terminology >>>> >>>> a) We have received guidance from Benoit Claise and the YANG Doctors that >>>> "YANG module" and "YANG data model" are preferred. We have updated the >>>> text to use these forms. Please review. >>>> >>>> b) Should instances of "LMP protocol" be updated to simply read "LMP" to >>>> avoid redundancy (if expanded, "LMP protocol" would read "Link Management >>>> Protocol protocol")? >>>> >>>> c) Similarly, should instances of "MPI interface" be updated to simply >>>> read "MPI" >>>> (if expanded, "MPI interface" would read "MDSC to PNC Interface >>>> interface")? >>>> --> >>>> [Haomian] I am good with all the 3 changes above. >>>> >>>> 12) <!-- [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. Updates of this nature >>>> typically result in more precise language, which is helpful for readers. >>>> >>>> For example, please consider whether "Man in the Middle" should be updated. >>>> --> >>>> [Haomian] I am not an expert on inclusive language, and I did not find >>>> anything need to be updated after checking the guideline. >>>> Regarding 'Man in the Middle', see >>>> https://en.wikipedia.org/wiki/Man-in-the-middle_attack and I don't think >>>> we can change the term so I personally prefer to keep it. If really >>>> matters, I am also fine to remove it from the sentence. >>>> >>>> >>>> Thank you. >>>> >>>> RFC Editor/st/ap >>>> >>>> >>>> On Jan 29, 2025, at 3:06 PM, rfc-edi...@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/01/29 >>>> >>>> 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 >>>> >>>> * rfc-edi...@rfc-editor.org (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). >>>> >>>> * auth48archive@rfc-editor.org, 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-4Q9l2USx >>>> I >>>> Ae6P8O4Zc >>>> >>>> * 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, >>>> auth48archive@rfc-editor.org 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/rfc9730.xml >>>> https://www.rfc-editor.org/authors/rfc9730.html >>>> https://www.rfc-editor.org/authors/rfc9730.pdf >>>> https://www.rfc-editor.org/authors/rfc9730.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9730-diff.html >>>> https://www.rfc-editor.org/authors/rfc9730-rfcdiff.html (side by >>>> side) >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9730-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9730 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9730 (draft-ietf-teas-gmpls-controller-inter-work-17) >>>> >>>> Title : Interworking of GMPLS Control and Centralized >>>> Controller Systems >>>> Author(s) : H. Zheng, Y. Xu, Y. Zhao, D. Beller, Y. Lin >>>> WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou Berger >>>> >>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde >>> >>> >> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
