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) <[email protected]> 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 <[email protected]> > 发送时间: 2025年2月7日 15:02 > 收件人: Zhenghaomian <[email protected]> > 抄送: [email protected]; [email protected]; > [email protected]; [email protected]; Linyi (Yi) > <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > 主题: 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 <[email protected]> wrote: >> >> Dear RFC editors, >> >> Thank you for the work, I reviewed the changes and approve the publication. >> >> Best wishes, >> Haomian >> >> -----邮件原件----- >> 发件人: Sarah Tarrant <[email protected]> >> 发送时间: 2025年2月6日 4:38 >> 收件人: Zhenghaomian <[email protected]> >> 抄送: [email protected]; [email protected]; >> [email protected]; [email protected]; Linyi (Yi) >> <[email protected]>; [email protected]; [email protected]; >> [email protected]; [email protected]; >> [email protected] >> 主题: 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 >>> <[email protected]> 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) >>> >>> -----邮件原件----- >>> 发件人: [email protected] <[email protected]> >>> 发送时间: 2025年1月30日 7:08 >>> 收件人: Zhenghaomian <[email protected]>; [email protected]; >>> [email protected]; [email protected]; Linyi (Yi) >>> <[email protected]> >>> 抄送: [email protected]; [email protected]; >>> [email protected]; [email protected]; >>> [email protected]; [email protected] >>> 主题: 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, [email protected] 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 >>> >>> * [email protected] (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). >>> >>> * [email protected], 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, >>> [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
