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/part2/*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/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX49XNI4bg$ > > * The archive itself: > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX6LXJmD5Q$ > > * 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/rfc9757.xml__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX66BrxHyA$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9757.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX649zNt6Q$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9757.pdf__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4aC2EY7Q$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9757.txt__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4-BeEDiA$ > > Diff file of the text: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9757-diff.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4CG3NKIA$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9757-rfcdiff.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4FRoxJRg$ > (side by side) > > Diff of the XML: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9757-xmldiff1.html__;!!NEt6yMaO-gk!ASsB8Ynp0YU98-bLgTxOlIP_d3X-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4vs4g9Rw$ > > > 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-IsZEDqbzQ7yOmzF20I4v0purcqhcKg6bApunKWWSozDrbpj6PX4yP8XcyQ$ > > 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
