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
