Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!--[rfced] The Abstract and Introduction mention that this document provides extensions for use with BGP-LS distribution and the SPF algorithm. Would you like to include "extensions" in the document title for consistency with the Abstract/Introduction? Also please consider the short title that appears in the header of the PDF file as shown below. Original: BGP Link-State Shortest Path First (SPF) Routing Option A (although it's not required to add "BGP-LS" into the title): BGP - Link State (BGP-LS) Shortest Path First (SPF) Routing Option B: Extensions for BGP Link-State Shortest Path First (SPF) Routing ... Short Title Original: BGP Link-State SPF Routing Option At: BGP - Link State SPF Routing --> 2) <!--[rfced] May we rephrase "are a matter of implementation detail" to "are specific to implementation" or "are specific to the implementation process" for clarity? Original: However, the details are a matter of implementation detail and out of scope for this document. Perhaps: However, the details are specific to implementation and are out of scope for this document. --> 3) <!--[rfced] In the RFC Series, "100s or 1000s" is typically spelled out. Would you like to spell it out as shown below for consistency? Original: With standard BGP path-vector routing, a single link failure may impact 100s or 1000s of prefixes and result in the withdrawal or re-advertisement of the attendant NLRI. Perhaps: With standard BGP path-vector routing, a single link failure may impact hundreds or thousands of prefixes and result in the withdrawal or re-advertisement of the attendant NLRI. --> 4) <!--[rfced] How may we rephrase "and realize all the above advantages" for clarity? Is the intended meaning that the BGP SPF topology "offers" the above advantages, as shown below? Original: Finally, the BGP SPF topology can be used as an underlay for other BGP SAFIs (using the existing model) and realize all the above advantages. Perhaps: Finally, the BGP SPF topology can be used as an underlay for other BGP SAFIs (using the existing model), and it offers all the above advantages. --> 5) <!--[rfced] FYI - We rephrased this sentence as shown below so that it's clear Sections 2 and 3 are in this document and not within RFCs 4271 and 9552. Original: The document begins with sections defining the precise relationship that BGP SPF has with both the base BGP protocol [RFC4271] (Section 2) and the BGP Link-State (BGP-LS) extensions [RFC9552] (Section 3). Current: This document begins with Section 2 defining the precise relationship that BGP SPF has with the base BGP protocol [RFC4271] and Section 3 defining the BGP - Link State (BGP-LS) extensions [RFC9552]. --> 6) <!--[rfced] Would you like the Requirements Language (Section 1.4) to follow the Terminology (Section 1.1)? --> 7) <!--[rfced] May we rephrase this sentence as follows so that it parses and is parallel with the third entry in the list? Original: Determining the degree of preference for BGP routes for the SPF calculation as described in phase 1 of the base BGP decision process is replaced with the mechanisms in Section 6.1. Perhaps: Phase 1 of the base BGP decision process, which determines the degree of preference for BGP routes for the SPF calculation, is replaced with the mechanisms in Section 6.1. --> 8) <!--[rfced] In RFC 4760, the term "Multiprotocol Extensions capabilities" is used rather than "Multi-Protocol Extensions Capability". We have updated the text below to reflect this. Note that there is another instance in Section 5.1. Please let us know if these changes are not correct. Original: Once the single-hop BGP session has been established and the Multi-Protocol Extensions Capability with the BGP-LS-SPF AFI/SAFI has been exchanged [RFC4760] for the corresponding session... Current: Once the single-hop BGP session has been established and the Multiprotocol Extensions capabilities have been exchanged with the BGP-LS-SPF AFI/SAFI [RFC4760] for the corresponding session... --> 9) <!--[rfced] The following sentence does not parse - are some words perhaps missing after "default"? Please let us know how we may rephrase for clarity. Original: When required, the default wait indefinitely for the EoR Marker prior to advertising the BGP-LS-SPF Link NLRI. Refer to Section 10.4. --> 10) <!--[rfced] May we update the title of Section 5 to reflect "Shortest Path First (SPF)" instead of "Shortest Path Routing (SPF)" for consistency? And may we remove the SPF expansion in the title of Section 5.1 since it was expanded in the title of Section 5? Original: 5. BGP Shortest Path Routing (SPF) Protocol Extensions . . . 9 5.1. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . 10 Perhaps: 5. BGP Shortest Path First (SPF) Routing Protocol Extensions . 9 5.1. BGP-LS SPF SAFI . . . . . . . . . . . . . . . . . . . . . 10 --> 11) <!--[rfced] FYI - We updated the following text to match the TLV names in RFC 9552. Original: For IPv4 links, the link's local IPv4 (TLV 259) and remote IPv4 (TLV 260) addresses are used. For IPv6 links, the local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses are used (Section 5.2.2 of [RFC9552]). Current: For IPv4 links, the link's local IPv4 interface address (TLV 259) and remote IPv4 neighbor address (TLV 260) are used. For IPv6 links, the local IPv6 interface address (TLV 261) and remote IPv6 neighbor address (TLV 262) are used (see Section 5.2.2 of [RFC9552]). --> 12) <!--[rfced] Section 5.2.2.1. For consistency, should instances of "Address Family Link Descriptor" be changed to "Address Family Link Descriptor TLV" here, for consistency with usage in the rest of the paragraph (which is not pasted below)? Original: For unnumbered links, the address family cannot be ascertained from the endpoint link descriptors. Hence, the Address Family (AF) Link Descriptor SHOULD be included with the Link Local/Remote Identifiers TLV for unnumbered links, so that the link can be used in the respective address family SPF. If the Address Family Link Descriptor is not present for an unnumbered link, the link will not be used in the SPF computation for either address family. If the Address Family Link Descriptor is present for a numbered link, the link descriptor will be ignored. --> 13) <!--[rfced] We updated the description for BGP status value "1" (Section 5.2.3.1) for consistency with IANA's "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status" registry <https://www.iana.org/assignments/bgp-spf/>, as shown below. We also placed the information in a table to match the formatting of similar text in Section 5.2.2.2. Tables 3 and 4 are both titled "BGP Status Values". Would you like to update one of the titles to differentiate the tables? Original: BGP Status Values: 0 - Reserved 1 - Prefix Unreachable with respect to SPF 2-254 - Undefined 255 - Reserved Current: +=======+============================================+ | Value | Description | +=======+============================================+ | 0 | Reserved | + - - - + - - - - - - - - - - - - - - - - - - - - - + | 1 | Prefix unreachable with respect to BGP SPF | + - - - + - - - - - - - - - - - - - - - - - - - - - -+ | 2-254 | Unassigned | + - - - + - - - - - - - - - - - - - - - - - - - - - -+ | 255 | Reserved | + - - - + - - - - - - - - - - - - - - - - - - - - - -+ Table 4: BGP Status Values --> 14) <!--[rfced] We note that "SPF Back-Off algorithm" is called the "SPF Back-Off Delay algorithm" in RFC 8405. We updated the text below for consistency. Please let us know of any objections. Original: The scheduling of the SPF calculation, as described in Section 6.3, is an implementation and/or configuration matter. Scheduling MAY be dampened consistent with the SPF back-off algorithm specified in [RFC8405]. Current: The scheduling of the SPF calculation, as described in Section 6.3, is an implementation and/or configuration matter. Scheduling MAY be dampened consistent with the SPF Back-Off Delay algorithm specified in [RFC8405]. --> 15) <!--[rfced] How may we clarify "as more recent" in the following text. Have BGP speakers been accepting the self-originated NLRIs recently (rather than "always"), as shown below? Original: This is due to the fact that BGP speakers adjacent to the router always accept self-originated NLRI from the associated speaker as more recent (rule #1). Perhaps: This is due to the fact that BGP speakers adjacent to the router have been recently accepting self-originated NLRIs from the associated speaker (per rule #1). --> 16) <!--[rfced] Please clarify "Prefix versus Node reachability" in the last sentence. Does "versus" mean "or" in this context? Also, we see "BGP-LS-SPF node reachability" in the first sentence. Should "node" be "Node" for consistency with "Node reachability" (e.g., "BGP-LS-SPF Node reachability")? Original: Local Route Information Base (Local-RIB) - This routing table contains reachability information (i.e., next hops) for all prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node reachability. Implementations may choose to implement this with separate RIBs for each address family and/or Prefix versus Node reachability. Perhaps: Local Route Information Base (Local-RIB): A routing table that contains reachability information (i.e., next hops) for all prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF Node reachability. Implementations may choose to implement this with separate RIBs for each address family and/or Prefix or Node reachability. --> 17) <!--[rfced] Please clarify what "less than" refers to - is it the metric's cost, length, or other? Original: If the Current-Prefix's corresponding prefix is in the Local-RIB and the Local-RIB metric is less than the Current-Prefix's metric, the Current-Prefix does not contribute to the route and the next Prefix NLRI is examined in Step 4. --> 18) <!--[rfced] May we update this sentence as shown below for improved readability and clarity? Original: If the Current-Prefix's corresponding prefix is not in the Local-RIB, the prefix is installed with the Current-Node's next-hops installed as the Local-RIB route's next-hops and the metric being updated. Perhaps: If the Current-Prefix's corresponding prefix is not in the Local-RIB, the prefix is installed with the Current-Node's next-hops, which are installed as the next-hops for the Local-RIB route and the metric being updated. --> 19) <!--[rfced] The following sentences do not parse, for example, "that the BGP-LS-LINK NLRI is advertised with SPF Status". How may we rephrase this text for clarity? Also, should "BGP-LS-LINK NLRI" be updated as "BGP-LS-SPF Link NLRI" in the first sentence and "BGP-LS-Prefix NLRI" be updated as "BGP-LS-SPF Prefix NLRI" in the second sentence for consistency? Original: The configurable LinkStatusDownAdvertise timer controls the interval that the BGP-LS-LINK NLRI is advertised with SPF Status indicating the link is down prior to withdrawal. The configurable PrefixStatusDownAdvertise timer controls the interval that the BGP-LS-Prefix NLRI is advertised with SPF Status indicating the prefix is unreachable prior to withdrawal. Perhaps: The configurable PrefixStatusDownAdvertise timer controls the interval when a BGP-LS-SPF Link NLRI has been advertised with the SPF Status TLV and indicates that the prefix is unreachable prior to withdrawal. The configurable PrefixStatusDownAdvertise timer controls the interval when a BGP-LS-SPF Prefix NLRI is advertised with the SPF Status TLV and indicates that the prefix is unreachable prior to withdrawal. --> 20) <!--[rfced] FYI, we placed the information in Table 5 in ascending order to match the "BGP-LS NLRI and Attribute TLVs" registry at <https://www.iana.org/assignments/bgp-ls-parameters/> --> 21) <!--[rfced] Please consider whether the registry names make sense with "Status" repeated, i.e., "Status TLV Status"? For example, is the meaning intact if the last word is removed? Or, we see examples of registry names that end with "TLV Types" or "TLV Values". Original [not a comprehensive list of instances]: the "BGP-LS-SPF Link NLRI Attribute SPF Status TLV Status" registry the "BGP-LS-SPF Node NLRI Attribute SPF Status TLV Status" registry the "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV Status" registry Perhaps (if removing the last word): the "BGP-LS-SPF Link NLRI Attribute SPF Status TLV" registry the "BGP-LS-SPF Node NLRI Attribute SPF Status TLV" registry the "BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV" registry --> 22) <!--[rfced] We having trouble parsing this sentence. Does the processing of the BGP SPF and BGP-LS-SPF SAFI cause the encoding to be inherited from BGP-LS (option A)? Or do BGP-LS-SPF SAFIs and processed BGP SPFs inherit the encoding (option B)? Please clarify. Original: The BGP SPF processing and the BGP-LS-SPF SAFI inherit the encoding from BGP-LS [RFC9552], and consequently, inherit the security considerations for BGP-LS associated with encoding. Perhaps A: When BGP SPF and BGP-LS-SPF SAFI are processed, they inherit encoding from BGP-LS [RFC9552] and, consequently, inherit the security considerations for the BGP-LS associated with encoding. Perhaps B: BGP-LS-SPF SAFIs and processed BGP SPFs inherit the encoding from BGP-LS [RFC9552] and, consequently, inherit the security considerations for BGP-LS associated with encoding. --> 23) <!--[rfced] How may we update this sentence for clarity? Original: Algorithms such as setting the metric inversely to the link speed as supported in some IGP implementations MAY be supported. Perhaps: Algorithms that set the metric inversely to the link speed in some IGP implementations MAY be supported. --> 24) <!--[rfced] In the first sentence, is "BGP-LS-SPF AFI/SAFI SPF" correct or should it perhaps be "BGP-LS-SPF AFI/SAFI"? In the second sentence, should "BGP SPF Link-State" perhaps be "BGP-LS-SPF" for consistency? Original: In common deployment scenarios, the unicast routes installed during BGP-LS-SPF AFI/SAFI SPF computation serve as the underlay for other BGP AFI/SAFIs. To avoid errors encountered in other AFI/SAFIs from impacting the BGP-LS-SPF AFI/SAFI or vice versa, isolation mechanisms such as separate BGP instances or separate BGP sessions (e.g., using different addresses for peering) for BGP SPF Link-State information distribution SHOULD be used. Perhaps: In common deployment scenarios, the unicast routes installed during BGP-LS-SPF AFI/SAFI computation serve as the underlay for other BGP AFI/SAFIs. To avoid errors encountered in other AFI/SAFIs from impacting the BGP-LS-SPF AFI/SAFI or vice versa, isolation mechanisms such as separate BGP instances or separate BGP sessions (e.g., using different addresses for peering) for BGP-LS-SPF information distribution SHOULD be used. --> 25) <!--[rfced] FYI - To avoid the repetition of "The authors would like to thank" in the Acknowledgements, we streamlined the text as follows: Original: The authors would like extend thanks Alvaro Retana for multiple AD reviews and discussions. The authors would to thank Ketan Talaulikar for an extensive shepherd review. The authors would like to thank Adrian Farrel, Li Zhang, and Jie Dong for WG last call review comments. The authors would to like to thank Jim Guichard for his AD review and discussion. The authors would to like to thank David Dong for his IANA review. The authors would to like to thank Joel Halpern for his GENART review. The authors would to like to thank Erik Kline, Eric Vyncke, Mahesh Jethanandani, and Roman Danyliw for IESG review comments. The authors would to like to thank John Scudder for his detailed IESG review and specifically for helping align the document with BGP documents. Current: The authors would also like to thank the following people: * Alvaro Retana for multiple AD reviews and discussions. * Ketan Talaulikar for an extensive shepherd review. * Adrian Farrel, Li Zhang, and Jie Dong for WG Last Call review comments. * Jim Guichard for his AD review and discussion. * David Dong for his IANA review. * Joel Halpern for his GENART review. * Erik Kline, Éric Vyncke, Mahesh Jethanandani, and Roman Danyliw for IESG review comments. * John Scudder for his detailed IESG review and specifically for helping align the document with BGP documents. --> 26) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> 27) <!-- [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. BGP Router vs. BGP router BGP SPF Router vs. BGP SPF router BGP-LS Attribute vs. BGP-LS attribute [Note: uppercase used in RFC 9552] BGP-LS Prefix Attribute vs. BGP-LS Prefix attribute BGP-LS-SPF Link NLRI vs. BGP-LS-SPF NLRI [Note: are these terms different or the same?] BGP-LS-SPF Node NLRI vs. BGP-LS-SPF NLRI [Note: are these terms different or the same?] Decision Process vs. decision process [Note: uppercase used in RFC 4271] Remote Node NLRI vs. Remote-Node NLRI UPDATE message vs. Update message vs. update message [Note: should this be "UPDATE message" per RFC 7606?] b) FYI - We updated the following terms to reflect the forms on the right for consistency. Please let us know of any objections. AS Number (TLV 512) -> Autonomous System (TLV 512) (per RFC 9552) back-off algorithm -> Back-Off algorithm (per RFC 8405) Error Handling -> error handling BGP update -> BGP Update BGP SPF Routing Domain -> BGP SPF routing domain BGP-SPF -> BGP SPF (2 instances) BGP-LS-SPF LINK NLRI -> BGP-LS-SPF Link NLRI EoR Marker -> EoR marker (per RFC 4724) IGP metric attribute TLV (TLV 1095) -> IGP Metric (TLV 1095) (per RFC 9552) link NLRI -> Link NLRI (1) local and remote node descriptors -> Local and Remote Node Descriptors local node descriptor -> Local Node Descriptor NLRI Link -> Link NLRI (1) Node identifiers -> Node Identifiers phase 1 -> Phase 1 Route Reflector -> route reflector (per RFC 4456) SAFI BGP-LS-SPF BGP Update -> BGP-LS-SPF SAFI BGP Update set 1 -> Step 1 Ships-in-the-Night -> ships-in-the-night (per other RFCs) Treat-as-withdraw -> treat-as-withdraw (per RFC 7606) Unequal Cost Multi-Path -> Unequal-Cost Multipath Unicast -> unicast c) In this document, we note one occurrence of "BGP-LS-SPF Attribute TLV", and it is not used in any other RFCs. Is this correct or does it need an update for consistency? Original: The BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined to indicate the status of the link with respect to the BGP SPF calculation. d) In this document, we note one occurrence each of "BGP-LS Node attribute" and "BGP-LS Link Attribute". Should these be updated as "BGP-LS Attribute" or other for consistency? Original: If the BGP-LS Node attribute includes an SPF Status TLV (refer to Section 5.2.1.1) indicating the node is unreachable, the Node NLRI is ignored and the next lowest cost Node NLRI is selected from the CAN-LIST. Original: If BGP-LS-SPF Link NLRI has been advertised with the SPF Status TLV and the link becomes available in that period, the originator of the BGP-LS-SPF LINK NLRI MUST advertise a more recent version of the BGP-LS-SPF Link NLRI without the SPF Status TLV in the BGP-LS Link Attributes. e) Should one instance of "local/remote link identifiers" perhaps be "Link Local/Remote Identifiers" for consistency? Original: For a link to be used in SPF computation for a given address family, i.e., IPv4 or IPv6, both routers connecting the link MUST have matching addresses (i.e., router interface addresses must be on the same subnet for numbered interfaces and the local/remote link identifiers (Section 6.3) must match for unnumbered interfaces). Perhaps: For a link to be used in SPF computation for a given address family, i.e., IPv4 or IPv6, both routers connecting the link MUST have matching addresses (i.e., router interface addresses must be on the same subnet for numbered interfaces, and the Link Local/Remote Identifiers (Section 6.3) must match for unnumbered interfaces). f) We note the following variations - are these terms different or the same? Please let us know if any should be updated for consistency. Link Local/Remote Identifiers (TLV 258) Link Remote Identifier Link's Remote Identifier Remote Link Identifier Remote Identifier Current or Remote Link's Local Identifier Current-Link's Remote Identifier As one example, how may we update this sentence for consistency? Should the reference to TLV 258 be "Link Local/Remote Identifiers" per RFC 9552 (option A)? Or should hyphens be added to "Current and Remote Link's" (option B)? Original: Since the Link's Remote Identifier may not be known, a value of 0 is considered a wildcard and will match any Current or Remote Link's Local Identifier (see TLV 258 [RFC9552]). Perhaps A: Since the Link Remote Identifier may not be known, a value of 0 is considered a wildcard and will match any Link Local/Remote Identifiers (see TLV 258 [RFC9552]). Perhaps B: Since the Link Remote Identifier may not be known, a value of 0 is considered a wildcard and will match any Current-Link or Remote-Link's Local Identifier (see TLV 258 [RFC9552]). g) We note inconsistencies with "next hop". May we update the document as shown below for consistency? Next-Hop vs. Next Hop vs. next-hop vs. next hop Some instances in the document: BGP Next-Hop Current-Node's next-hops Local-RIB Next-Hop Local-RIB route's next-hops MP_REACH_NLRI Next-Hop The Next Hop in the MP_REACH_NLRI attribute (i.e., next hops) the next-hop for... Perhaps: BGP Next-Hop (per RFC 9552) Local-RIB Next-Hop MP_REACH_NLRI Next-Hop When used in general: lowercase open form or hyphenated when preceding a noun (e.g., "The next-hop list is set to the internal loopback next hop"). --> 28) <!-- [rfced] Abbreviations a) 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. Autonomous System (AS) Bidirectional Forwarding Detection (BFD) Network Layer Reachability Information (NLRI) Unequal-Cost Multipath (UCMP) b) We note "LSDB" and "LSNDB". Are these different databases or should they be updated for consistency? Link State Database (LSDB) (per RFC 9552) Link State NLRI Database (LSNDB) c) We updated the following expansions to reflect the form on the right for consistency with the RFC Series: BGP Link-State (BGP-LS) -> BGP - Link State (BGP-LS) (per RFC 9552) Equal-Cost Multi-Path (ECMP) -> Equal-Cost Multipath (ECMP) Internal Gateway Protocols (IGPs) -> Interior Gateway Protocols (IGPs) Subsequent Address Families Identifiers (SAFIs) -> Subsequent Address Family Identifiers (SAFIs) --> 29) <!-- [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. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/kc/ar On Jun 30, 2025, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/06/30 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/rfc9815.xml https://www.rfc-editor.org/authors/rfc9815.html https://www.rfc-editor.org/authors/rfc9815.pdf https://www.rfc-editor.org/authors/rfc9815.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9815-diff.html https://www.rfc-editor.org/authors/rfc9815-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9815-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9815 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9815 (draft-ietf-lsvr-bgp-spf-51) Title : BGP Link-State Shortest Path First (SPF) Routing Author(s) : K. Patel, A. Lindem, S. Zandi, W. Henderickx WG Chair(s) : Jie Dong, Acee Lindem Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
