Hi Aijun and John, Thank you for your replies. The files have been updated accordingly.
> On Mar 4, 2025, at 6:37 PM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > One minor question, should the table 4 in > https://www.rfc-editor.org/authors/rfc9757.html#section-13.4add another > column, to point also to RFC 9757? We have added a Reference column to Table 4. > I noticed that the IANA allocation in > https://www.iana.org/assignments/pcep/pcep.xhtml (the code points that are > related to Native IP) have such pointers(I think they should be updated later > to point to RFC 9757?) After this document is published, IANA will update the corresponding references to point to RFC 9757. ... The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9757.xml https://www.rfc-editor.org/authors/rfc9757.txt https://www.rfc-editor.org/authors/rfc9757.html https://www.rfc-editor.org/authors/rfc9757.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9757-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9757-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9757-lastdiff.html (htmlwdiff diff between last version and this) https://www.rfc-editor.org/authors/rfc9757-lastrfcdiff.html (rfcdiff between last version and this) Aijun’s approval has been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9757 Once we receive approvals from Boris, Sheng, Ren, and Chun, we will move this document forward in the publication process. Thank you, RFC Editor/ap > On Mar 4, 2025, at 6:37 PM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > Hi, Alanna and John: > > Thanks for your help to forward this document. > For the remained query, I think the suggested description is more clear. > Thanks for your efforts. > > One minor question, should the table 4 in > https://www.rfc-editor.org/authors/rfc9757.html#section-13.4add another > column, to point also to RFC 9757? > I noticed that the IANA allocation in > https://www.iana.org/assignments/pcep/pcep.xhtml (the code points that are > related to Native IP) have such pointers(I think they should be updated later > to point to RFC 9757?) > > I have no other comment for the current version and support its publication. > > Thanks all for your efforts! > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: Alanna Paloma [mailto:apal...@staff.rfc-editor.org] > 发送时间: 2025年3月5日 8:26 > 收件人: John Scudder <jgs=40juniper....@dmarc.ietf.org>; Aijun Wang > <wangai...@tsinghua.org.cn>; bhassa...@yahoo.com; fsh...@huawei.com; > tan...@huawei.com; zhu.ch...@zte.com.cn > 抄送: RFC Editor <rfc-edi...@rfc-editor.org>; pce-ads <pce-...@ietf.org>; > pce-chairs <pce-cha...@ietf.org>; Dhruv Dhody <d...@dhruvdhody.com>; > auth48archive <auth48archive@rfc-editor.org> > 主题: Re: AUTH48: RFC-to-be 9757 <draft-ietf-pce-pcep-extension-native-ip-40> > for your review > > Hi Authors and John (AD), > > Thank you for your replies. John’s approval has been noted on the AUTH48 > status page, and we have updated the files accordingly. > > Please note that we have a follow-up query: > >> 4) <!--[rfced] Does "their" refer to "PCECC-CAPABILITY sub-TLV"? If yes, may >> we update "their" to "its" for clarity? >> >> Original: >> [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange >> information about their PCECC capability. >> >> Perhaps: >> [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange >> information about its PCECC capability. >> -->[WAJ]: No, here "their" refers to the PCEP Speakers (PCE or PCC). Then, >> keep the previous statement is better. > > ) To further clarify “their”, may we update the text as follows? > > Perhaps: > [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange > information about the PCEP speakers' PCECC capability. > [WAJ]Yes, such statements is more clear, thanks! > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9757.xml > https://www.rfc-editor.org/authors/rfc9757.txt > https://www.rfc-editor.org/authors/rfc9757.html > https://www.rfc-editor.org/authors/rfc9757.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9757-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9757-auth48diff.html (AUTH48 changes) > > Please review the document carefully and contact us with any further updates > you may have. Note that we do not make changes once a document is published > as an RFC. > > We will await approvals from each party listed on the AUTH48 status page > below prior to moving this document forward in the publication process. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9757 > > Thank you, > RFC Editor/ap > > >> On Mar 4, 2025, at 10:32 AM, John Scudder <jgs=40juniper....@dmarc.ietf.org> >> wrote: >> >> Yes, regarding #18, please remove the note as requested in the body text. >> >> Thanks, >> >> —John >> >>> On Mar 3, 2025, at 3:19 PM, rfc-edi...@rfc-editor.org wrote: >>> >>> Authors and *AD, >>> >>> While reviewing this document during AUTH48, please resolve (as >>> necessary) the following questions, which are also in the XML file. >>> >>> *AD, please see #18. >>> >>> 1) <!--[rfced] How may we clarify the latter part of this sentence? >>> >>> Original: >>> These extensions empower a PCE to calculate and manage paths >>> specifically for native IP networks, expand PCEP's capabilities >>> beyond its traditional use in MPLS and GMPLS networks. >>> >>> Perhaps: >>> These extensions empower a PCE to calculate and manage paths >>> specifically for native IP networks, thereby expanding PCEP's >>> capabilities beyond its traditional use in MPLS and GMPLS networks. >>> --> >>> >>> >>> 2) <!--[rfced] To avoid awkward hyphenation, may we update the text >>> below as follows? >>> >>> Original: >>> [RFC8821] describes the architecture and solution philosophy for the >>> E2E traffic assurance in the Native IP network via multiple Border >>> Gateway Protocol (BGP) sessions-based solution. >>> >>> Perhaps: >>> [RFC8821] describes the architecture and solution philosophy for the >>> E2E traffic assurance in the Native IP network via a solution based >>> on multiple Border Gateway Protocol (BGP) sessions. >>> --> >>> >>> >>> 3) <!-- [rfced] This sentence implies that the status of this >>> document could change in the future. May we update the text to state >>> that a new document would be published in order to update the status? >>> >>> Original: >>> Feedback from deployments will be >>> crucial in determining whether this specification should advance >>> from Experimental to the IETF Standards Track. >>> >>> Perhaps: >>> Feedback from deployments will be >>> crucial in determining whether a future document will be published >>> to advance this specification from Experimental to the IETF Standards >>> Track. >>> --> >>> >>> >>> 4) <!--[rfced] Does "their" refer to "PCECC-CAPABILITY sub-TLV"? If >>> yes, may we update "their" to "its" for clarity? >>> >>> Original: >>> [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange >>> information about their PCECC capability. >>> >>> Perhaps: >>> [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange >>> information about its PCECC capability. >>> --> >>> >>> >>> 5) <!--[rfced] To improve readability, may we update this sentence as >>> follows? Please review and ensure that the suggested text does not >>> alter the intended meaning. >>> >>> Original: >>> The PCECC Native IP TE solution uses the existing PCE Label Switched >>> Path (LSP) Initiate Request message (PCInitiate) [RFC8281], and PCE >>> Report message (PCRpt) [RFC8231] to accomplish the multiple BGP >>> sessions establishment, E2E Native-IP TE path deployment, and route >>> prefixes advertisement among different BGP sessions. >>> >>> Perhaps: >>> The PCECC Native IP TE solution uses the existing PCE Label Switched >>> Path (LSP) Initiate Request message (PCInitiate) [RFC8281] and PCE >>> Report message (PCRpt) [RFC8231] to establish multiple BGP sessions, >>> deploy the E2E Native-IP TE path, and advertise route prefixes among >>> different BGP sessions. >>> --> >>> >>> >>> 6) <!-- [rfced] Please review the "type" attribute of each sourcecode >>> element in the XML file to ensure correctness. If the current list of >>> preferred values for "type" >>> (https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku >>> .php?id=sourcecode-types__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX6JnjxABA$ >>> ) does not contain an applicable type, then feel free to let us know. >>> Also, it is acceptable to leave the "type" attribute not set. >>> --> >>> >>> >>> 7) <!--[rfced] May we make the following sentences more concise by >>> removing "instance of"? Please review the suggested text and let us >>> know if this change alters the intended meaning. >>> >>> Original: >>> If there is >>> more than one instance of BPI, EPR or PPA object present, the >>> receiving PCC MUST send a PCErr message with Error-type=19 (Invalid >>> Operation) and Error-value=22 (Only one BPI, EPR or PPA object can >>> be included in this message). >>> ... >>> If there are >>> more than one instance of BPI, EPR or PPA objects present, the >>> receiving PCE MUST send a PCErr message with Error-type=19 (Invalid >>> Operation) and Error-value=22 (Only one BPI, EPR or PPA object can >>> be included in this message). >>> >>> Perhaps: >>> If there is >>> more than one BPI, EPR, or PPA object present, the receiving PCC >>> MUST send a PCErr message with Error-type=19 (Invalid >>> Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can >>> be included in this message). >>> ... >>> If there is >>> more than one BPI, EPR, or PPA object present, the receiving PCE >>> MUST send a PCErr message with Error-type=19 (Invalid >>> Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can >>> be included in this message). >>> --> >>> >>> >>> 8) <!--[rfced] To avoid the repetition of "object", may we update the >>> sentence below? >>> >>> Original: >>> Furthermore, one, and only one, object among BPI, EPR or PPA object >>> MUST be present. >>> >>> Perhaps: >>> Furthermore, one and only one BPI, EPR, or PPA object MUST be present. >>> --> >>> >>> >>> 9) <!--[rfced] How may we clarify "to the same destination"? >>> >>> Original: >>> If there is traffic >>> from different attached points to the same destination coming into >>> the network, they could share the priority path which may not be the >>> initial desire. >>> >>> Perhaps: >>> If traffic is coming into the network from different attached points >>> but to the same destination, they could share the priority path, >>> which may not be the initial desire. >>> --> >>> >>> >>> 10) <!--[rfced] We don't see the term "IPinIP" in RFC 2003. Should >>> this be updated as "IP in IP"? Note that other RFCs generally use "IP-in-IP" >>> when referring to tunnels. >>> >>> We also see "IPnIP" in Table 8 - is this term the same as "IPinIP" or >>> different? Please let us know if/how these terms may be updated for >>> consistency. >>> >>> Original: >>> Section 6.4 >>> For simplicity, the IPinIP tunnel type [RFC2003] is used between the >>> BGP peers by default. >>> >>> Section 7.2 >>> Currently, only bit 7 (T bit) is defined. When the T bit is set, >>> the traffic SHOULD be sent in the IPinIP tunnel (Tunnel source is >>> Local IP Address, tunnel destination is Peer IP Address). >>> >>> Table 8 >>> 7 | T (IPnIP) bit | >>> --> >>> >>> >>> 11) <!--[rfced] Per use elsewhere throughout the document, should "R flag" >>> be updated to "R bit"? >>> >>> Original: >>> To remove the Native-IP state from the PCC, the PCE MUST send >>> explicit CCI cleanup instructions for PPA, EPR and BPI objects >>> respectively with the R flag set in the SRP object. >>> >>> Perhaps: >>> To remove the Native-IP state from the PCC, the PCE MUST send >>> explicit CCI cleanup instructions for PPA, EPR, and BPI objects, >>> respectively, with the R bit set in the SRP object. >>> --> >>> >>> >>> 12) <!--[rfced] FYI - To match Sections 7.2 and 7.3, we have updated >>> the single sentence preceding Figures 14 and 15 in Section 7.4 to be >>> two sentences, one preceding each figure, respectively. Please review >>> and let us know of any objections. >>> >>> Original: >>> The format of the Peer Prefix Advertisement object body is as >>> follows: >>> >>> Current: >>> The format of the Peer Prefix Advertisement object body for IPv4 is >>> as follows: >>> ... >>> The format of the Peer Prefix Advertisement object body for IPv6 is >>> as follows: >>> --> >>> >>> >>> 13) <!-- [rfced] Table 1: Rather than have two tables with the same >>> information, may we point readers to Table 5 in the IANA >>> Considerations section as shown below? >>> >>> Current (Section 8): >>> An additional Error-Type and several Error-values are defined to >>> represent the errors related to the newly defined objects that are >>> related to Native IP TE procedures. >>> >>> Perhaps: >>> An additional Error-Type and several Error-values are defined to >>> represent the errors related to the newly defined objects that are >>> related to Native IP TE procedures. See Table 5 (Section 13.4) for >>> the newly defined Error-Type and Error-values. >>> --> >>> >>> >>> 14) <!--[rfced] To have a 1:1 matchup between the acronym and its >>> expansion, may we update "LSP-DB" as follows, i.e., remove "State" from the >>> expansion? >>> >>> Original: >>> ...treat the three newly defined objects (BPI, EPR and PPA) >>> associated with the same symbolic path name as the attribute of the >>> same path in the LSP-DB (LSP State Database). >>> >>> Perhaps: >>> ...treat the three newly defined objects (BPI, EPR, and PPA) >>> associated with the same symbolic path name as the attribute of the >>> same path in the LSP Database (LSP-DB). >>> --> >>> >>> >>> 15) <!--[rfced] Is the intended meaning that the mechanisms in this >>> document and the mechanisms listed in RFC 5440 do not imply any new >>> liveness detection and monitoring? If so, may we rephrase the text as >>> shown below for clarity? >>> >>> Original: >>> Mechanisms defined in this document do not imply any new liveness >>> detection and monitoring requirements in addition to those already >>> listed in [RFC5440]. >>> >>> Perhaps: >>> Mechanisms defined in this document, and those already listed in >>> [RFC5440], do not imply any new liveness detection and monitoring >>> requirements. >>> --> >>> >>> >>> 16) <!--[rfced] Does "it" refer to a suitable default value? If so, >>> may we clarify the text as follows? >>> >>> Original: >>> If suitable default values as discussed in Section 9 aren't enough >>> and securing the BGP transport is required(for example, the TCP-AO >>> [RFC5925], it can be provided through the addition of optional TLVs >>> to the BGP Peer Info object that conveys the necessary additional >>> information (for example, a key chain [RFC8177]name). >>> >>> Perhaps: >>> If the suitable default values discussed in Section 9 aren't enough >>> and securing the BGP transport is required (for example, by using >>> TCP-AO [RFC5925]), a suitable value can be provided through the >>> addition of optional TLVs to the BGP Peer Info object that conveys >>> the necessary additional information (for example, a key chain >>> [RFC8177] name). >>> --> >>> >>> >>> 17) <!-- [rfced] We have included a clarification about the IANA text >>> below. In addition to reviewing it, please review all of the >>> IANA-related updates carefully and let us know if any further updates >>> are needed. >>> >>> ) FYI: In Table 4, we have added "Object-Type" to each name and have >>> added >>> "0: Reserved" accordingly to match the "PCEP Objects" registry (see >>> <https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX5NrI4xsQ$ >>> >). >>> --> >>> >>> >>> 18) <!--[rfced] *AD - Per the following note left in the document by >>> the authors, we have removed the normative reference >>> [I-D.ietf-pce-iana-update]. Please review and approve of this update. >>> >>> Original: >>> Editorial Note (To be removed by RFC Editor): This experimental >>> track document is allocating a code point in the registry under the >>> standards action registry which is not allowed. >>> [I-D.ietf-pce-iana-update] updates the registration policy to IETF >>> review allowing for this allocation. Note that an early allocation >>> was made when the document was being progressed in the standards >>> track. At the time of publication, please remove this note and the >>> reference to [I-D.ietf-pce-iana-update]. >>> --> >>> >>> >>> 19) <!-- [rfced] The following reference is not cited in the text. >>> Please let us know where it should be cited; otherwise, it will be >>> deleted from the references section. >>> >>> [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running >>> Code: The Implementation Status Section", BCP 205, >>> RFC 7942, DOI 10.17487/RFC7942, July 2016, >>> >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc7942__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4VjRUtWQ$ >>> >. >>> --> >>> >>> >>> 20) <!-- [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. >>> >>> Path Computation Client (PCC) >>> PCEP-specific LSP identifiers (PLSP-ID) TCP Authentication Option >>> (TCP-AO) >>> --> >>> >>> >>> 21) <!-- [rfced] Terminology >>> >>> a) Throughout the text, the following terminology appears to be used >>> inconsistently. Please review these occurrences and let us know >>> if/how they may be made consistent. >>> >>> Local/Peer IP Address vs. Local/Peer IP address >>> >>> Native IP vs. Native-IP vs. native IP vs. NATIVE IP >>> [Note: These differences are also found within the IANA registries.] >>> >>> Peer IPv4 Address vs. peer IPv4 address Peer IPv6 Address vs. peer >>> IPv6 address >>> >>> b) May we update the following terms to the form on the right in the >>> running text for consistency? >>> >>> central controller instructions > Central Controller Instructions >>> (per RFC 9050) code point > codepoint (per RFC 9050 and to match the >>> companion document) Error-type > Error-Type Error-Value > Error-value >>> Object type, object type > Object-Type PCE-Initiated > PCE-initiated >>> (per RFC 8281) PCEP Speakers > PCEP speakers PCInitiate Message > >>> PCInitiate message state synchronization > State Synchronization (per >>> RFCs 8232 and 9050) Symbolic Path Name > symbolic path name (per RFC >>> 8232) Remote Peer > remote peer (per RFC 8232) >>> >>> PCEP Object > PCEP object >>> BPI Object > BPI object >>> CCI Object > CCI object >>> >>> c) We note three instances of "PCEP protocol". Since this reads as >>> "Path Computation Element Communication Protocol protocol" when >>> expanded, may we remove "protocol" when it occurs after "PCEP"? >>> >>> d) FYI: We note "Central Control Dynamic Routing" vs. "Centralized >>> Control Dynamic Routing" for the expansion of "CCDR". We have updated >>> the text to reflect the latter form per use in RFCs 8735 and 8821. >>> >>> Central Control Dynamic Routing > Centralized Control Dynamic Routing >>> --> >>> >>> >>> 22) <!-- [rfced] Please review the "Inclusive Language" portion of >>> the online Style Guide >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/pa >>> rt2/*inclusive_language__;Iw!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX7aoLFAuQ$ >>> > 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 the following should be updated: >>> - traditional >>> - native >>> --> >>> >>> >>> Thank you. >>> >>> RFC Editor/ap/kc >>> >>> >>> On Mar 03, 2025, at 12:15 AM, rfc-edi...@rfc-editor.org wrote: >>> >>> *****IMPORTANT***** >>> >>> Updated 2025/03/03 >>> >>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX7V2sHg-A$ >>> ). >>> >>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4GK5eOgQ$ >>> ). >>> >>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX7AOikOGg$ >>> >. >>> >>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/iet >>> f-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!ASsB8Ynp0YU98- >>> bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX49XNI >>> 4bg$ >>> >>> * The archive itself: >>> >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/ >>> auth48archive/__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7 >>> yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX6LXJmD5Q$ >>> >>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc975 >>> 7.xml__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4 >>> v0purcqhcKg6bApunKWWSozDrbpj6PX66BrxHyA$ >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc975 >>> 7.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I >>> 4v0purcqhcKg6bApunKWWSozDrbpj6PX649zNt6Q$ >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc975 >>> 7.pdf__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4 >>> v0purcqhcKg6bApunKWWSozDrbpj6PX4aC2EY7Q$ >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc975 >>> 7.txt__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4 >>> v0purcqhcKg6bApunKWWSozDrbpj6PX4-BeEDiA$ >>> >>> Diff file of the text: >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc975 >>> 7-diff.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOm >>> zF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4CG3NKIA$ >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc975 >>> 7-rfcdiff.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7 >>> yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4FRoxJRg$ (side by side) >>> >>> Diff of the XML: >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc975 >>> 7-xmldiff1.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ >>> 7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4vs4g9Rw$ >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9757 >>> __;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0pur >>> cqhcKg6bApunKWWSozDrbpj6PX4yP8XcyQ$ >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC9757 (draft-ietf-pce-pcep-extension-native-ip-40) >>> >>> Title : Path Computation Element Communication Protocol (PCEP) >>> Extensions for Native IP Networks >>> Author(s) : A. Wang, B. Khasanov, S. Fang, R. Tan, C. Zhu >>> WG Chair(s) : Julien Meuric, Dhruv Dhody >>> >>> 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
