Hi Dieter, This is a friendly reminder that we have yet to hear back from 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 24, 2025, at 8:24 AM, Sarah Tarrant <starr...@staff.rfc-editor.org> > wrote: > > Hi Yang, > > 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 await approvals from the remaining parties listed at the AUTH48 > status page prior to moving this document forward in the publication process. > > Thank you, > RFC Editor/st > >> On Feb 24, 2025, at 12:55 AM, zhaoyang...@chinamobile.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. >> >> Thanks >> >> Yang Zhao >> China Mobile Research Institute >> From: Sarah Tarrant >> Date: 2025-02-19 22:25 >> To: xuyun...@caict.ac.cn; zhaoyang...@chinamobile.com; >> dieter.bel...@nokia.com >> CC: Linyi (Yi); rfc-edi...@rfc-editor.org; teas-...@ietf.org; >> teas-cha...@ietf.org; vbee...@juniper.net; james.n.guich...@futurewei.com; >> auth48archive@rfc-editor.org; Zhenghaomian >> Subject: Re: AUTH48: RFC-to-be 9730 >> <draft-ietf-teas-gmpls-controller-inter-work-17> for your review >> 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
