Hi, RFC Editors: Thanks for your diligent work to improve the readiness of this document! The detail responses for your questions are inline below, please review them.
We leave the question #18 for the AD to response, although we think the redundant contents should be removed after the publication of [I-D.ietf-pce-iana-update] Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: www...@rfcpa.rfc-editor.org [mailto:www...@rfcpa.rfc-editor.org] 代表 rfc-edi...@rfc-editor.org 发送时间: 2025年3月4日 4:19 收件人: wangai...@tsinghua.org.cn; bhassa...@yahoo.com; fsh...@huawei.com; tan...@huawei.com; zhu.ch...@zte.com.cn 抄送: rfc-edi...@rfc-editor.org; pce-...@ietf.org; pce-cha...@ietf.org; d...@dhruvdhody.com; j...@juniper.net; auth48archive@rfc-editor.org 主题: [AD] Re: AUTH48: RFC-to-be 9757 <draft-ietf-pce-pcep-extension-native-ip-40> for your review 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. -->[WAJ]: The latter is better. 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. -->[WAJ]: Yes, the latter is better. 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. -->[WAJ]: No, the previous is better. Change one RFC from Experimental to Standard Track doesn't always need one future new document. 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. 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. -->[WAJ]: Yes, The latter is more readable. 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. -->[WAJ]. The "type" attribute of each source code element in this XML file, should be "ABNF", instead of "xbnf", please update them (it seems there are only two occurrences) 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). --> [WAJ] Yes, the latter is better. 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. --> [WAJ] Yes, the latter is better. 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. --> [WAJ] Yes, the latter is better. 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 | -->[WAJ] They should all be updated as IP-in-IP 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. -->[WAJ]: Yes, the latter is better. 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: -->[WAJ]: Yes. The latter is better. I have no objection. 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. -->[WAJ]: Yes. The latter is better. 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). -->[WAJ]: Yes. The latter is better. 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. -->[WAJ]: The following statement is more better: Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements beyond those already listed in [RFC5440]. 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). --> [WAJ] The latter is better. But can we pull out the first "suitable" for more concise? Like the below: If the 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://www.iana.org/assignments/pcep/>). -->[WAJ] Should value 1(IPv4 address), 2(IPv6 address)'s reference also point to RFC 9757? And, if we remove table 1(as per the above question 13), should we renumber the other tables in section 13 from the beginning? I reviewed other IANA-related updates, and found no further necessary changes. 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://www.rfc-editor.org/info/rfc7942>. -->[WAJ]: Yes, it can be deleted. 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) -->[WAJ] OK. They are correct. 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 -->[WAJ] For a), it will be better to use these terminologies: Local/Peer IP Address, Native IP, Peer IPv4 Address, Peer IPv6 Address. Capitalize these terminologies can make the reader to aware their importance. For b), It will be better to capitalize all the related terminologies to keep the consistency, as that for the above answer a). For example, should keep "Remote Peer" as its current state, and also the "Symbolic Path Name"? It is better to use PCEP object, BPI object, CCI object, unless they are in the section title position. For c), it is better to use "PCEP", instead of "PCEP protocol" For d), OK, thanks! 22) <!-- [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 the following should be updated: - traditional - native -->[WAJ] There is no other more suitable words to have the similar meaning of the "traditional", "native" word. The recommended words in https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1 is more difficult for the readers. Let's keep it then? And we should notice that in cloud area, the "cloud native" has been widely accepted. 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://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-4Q9l2USxIAe6P8O4Zc * 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/rfc9757.xml https://www.rfc-editor.org/authors/rfc9757.html https://www.rfc-editor.org/authors/rfc9757.pdf https://www.rfc-editor.org/authors/rfc9757.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9757-diff.html https://www.rfc-editor.org/authors/rfc9757-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9757-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9757 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
