Hi Dhananjaya, Thanks for your update and letting us know. We will await your review and responses; let us know if we can be of any assistance in the meantime.
All best, Kaelin Foody RFC Production Center > On Oct 3, 2025, at 9:43 AM, Dhananjaya Rao (dhrao) <[email protected]> wrote: > > Hi Kaelin, > > We are working on the comments and questions; will share the response shortly. > > Regards, > -Dhananjaya > > From: Kaelin Foody <[email protected]> > Date: Friday, October 3, 2025 at 7:09 PM > To: [email protected] <[email protected]> > Cc: Dhananjaya Rao (dhrao) <[email protected]>, Swadesh Agrawal (swaagraw) > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9871 <draft-ietf-idr-bgp-car-16> for your > review > > Greetings, > > This is a friendly reminder that this document awaits author attention. > Please see the document-specific questions and AUTH48 announcement in this > thread and let us know if we can be of assistance as you begin the AUTH48 > review process. > > The AUTH48 status page of this document is available here: > http://www.rfc-editor.org/auth48/rfc9871 > > AUTH48 FAQs are available here: > https://www.rfc-editor.org/faq/#auth48. > > We look forward to hearing from you at your earliest convenience. > > Thank you, > > Kaelin Foody > RFC Production Center > > > On Sep 25, 2025, at 6:19 PM, [email protected] wrote: > > > > Authors, > > > > While reviewing this document during AUTH48, please resolve (as necessary) > > the following questions, which are also in the source file. > > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > 2) <!-- [rfced] Section 1.1. Terminology: We have made the following > > changes in > > this section; please review and let us know if any adjustments are needed. > > > > a) We have updated the text below to clarify the order of preference: > > > > Original: > > If several such paths exist, a preference scheme is used to select the best > > path (for example, IGP Flex-Algo preferred over SR Policy preferred over > > BGP CAR. > > > > Current: > > If several such paths exist, a preference scheme is used to select the best > > path (for example, IGP Flex-Algo is preferred over SR Policy, and SR Policy > > is preferred over BGP CAR). > > > > > > b) We have updated "trust domain" to "trusted domain" in the text below > > for consistency with RFC 8402. > > > > Original: > > In an SR deployment, the transport network is within a trust domain as per > > [RFC8402]. > > > > Current: > > In an SR deployment, the transport network is within a trusted domain as > > per > > [RFC8402]. > > --> > > > > > > 3) <!-- [rfced] Section 1.1. (Abbreviations): We have the following > > questions regarding the abbreviations list in this section. > > > > a) We were unable to find the term "BGP-LU" or "BGP Labeled Unicast SAFI" > > mentioned in RFC 8277. Is it the correct reference for this term? > > > > In addition, we also note the following different uses of this term > > throughout > > this document. Please review and let us know how to update for consistency. > > > > BGP IP/LU > > BGP LU > > BGP-IP/LU(Labeled Unicast) > > BGP LU/IP > > > > Original: > > * BGP-LU: BGP Labeled Unicast SAFI [RFC8277]. > > > > > > b) We were unable to find the term "BGP-IP" or "BGP IPv4/IPv6 Unicast > > AFI/SAFIs" > > in RFCs 4271 and 4760. How may we update? > > > > Original: > > * BGP-IP: BGP IPv4/IPv6 Unicast AFI/SAFIs [RFC4271], [RFC4760]. > > > > > > c) FYI - We have already made the following updates to this section. Please > > review. > > > > i) We have separated this list item into two separate entries for clarity > > and > > have updated their definitions for consistency with RFC 4760: > > > > Original: > > > > * AFI/SAFI: BGP Address-Family/Sub-Address-Family Identifiers. > > > > Current: > > > > AFI: Address Family Identifier > > > > SAFI: Subsequent Address Family Identifier > > > > ii) We have added list entries for the following terms so that they do > > not need to be expanded when they appear in figures or other list items. > > > > ABR: Area Border Router > > ASBR: Autonomous System Border Router > > RD: Route Distinguisher > > --> > > > > > > 4) <!-- [rfced] Section 2.1: For consistency with the rest of the list > > items in > > this section, what definition/content should appear for "BGP Next Hop"? > > > > Original: > > * BGP Next Hop. > > --> > > > > > > 5) <!-- [rfced] Please clarify the last two points; we suggest making them > > complete sentences and consistent with one another. More specifically, > > what is the outcome of the "if" clause in the final list item below (the > > item that begins with "Another example is:")? > > > > Original: > > * A BGP color-aware route (E2, C1) with next hop N may be resolved > > over a color-aware route (N, C2): i.e., the local policy maps the > > resolution of C1 over a different color C2. > > > > - For example, in a domain where resource R is known to not be > > present, the inter-domain intent C1="low delay and avoid R" may > > be resolved over an intra-domain path of intent C2="low delay". > > > > - Another example is: if no (N, C1) path is available and the user has > > allowed resolution to fallback to a C2 path. > > > > Perhaps: > > - For example, in a domain where resource R is known to not be > > present, the inter-domain intent C1="low delay and avoid R" may > > be resolved over an intra-domain path of intent C2="low delay". > > > > - For another example, if no (N, C1) path is available, and the user > > has > > allowed resolution to fallback to a C2 path, then ... [what outcome > > occurs]? > > --> > > > > > > 6) <!-- [rfced] How may we clarify how the content in parentheses relates to > > the rest of the sentence? > > > > Original: > > For CAR route resolution, Color-EC color if present takes precedence > > over the route's intent color (LCM-EC if present (Section 2.9.5), or > > else NLRI color). > > > > Perhaps: > > If present, Color-EC color takes precedence over the route's intent color > > (which, if present, is LCM-EC (see Section 2.9.5) or else NLRI color) for > > CAR route resolution. > > --> > > > > > > 7) <!-- [rfced] What is the subject of "or appropriately incremented" in > > the text below? > > > > Original: > > The value set (or appropriately incremented) in the AIGP TLV > > corresponds to the metric associated with the underlying intent of > > the color. > > > > Perhaps: > > The value that is set (or appropriately incremented) in the AIGP TLV > > corresponds to the metric associated with the underlying intent of > > the color. > > --> > > > > > > 8) <!-- [rfced] FYI - We adjusted these list items to make them parallel > > and consistent. Please review and let us know any further updates. > > > > Original: > > BGP CAR SRv6 SID TLV definitions provide the following benefits: > > > > * Native encoding of SIDs avoids robustness issue caused by > > overloading of MPLS label fields. > > > > * Simple encoding to signal Unique SIDs (non-transposition), > > maintaining BGP update prefix packing. > > > > * Highly efficient transposition scheme (12-14 bytes saved per > > NLRI), also maintaining BGP update prefix packing. > > > > Current: > > BGP CAR SRv6 SID TLV definitions provide the following benefits: > > > > * The native encoding of SIDs avoids robustness issues caused by the > > overloading of MPLS label fields. > > > > * The simple encoding to signal Unique SIDs (non-transposition) > > maintains BGP update prefix packing. > > > > * The highly efficient transposition scheme (12-14 bytes saved per > > NLRI) also maintains BGP update prefix packing. > > --> > > > > > > 9) <!-- [rfced] May we update the list below as follows for consistency? > > Is it intentional that the first "must" is lowercase, or should it be the > > all-caps requirement keyword "MUST" (which is used in the other bullet > > point)? > > > > Original: > > Given NLRI length and Key length MUST be valid, failures in following > > checks result in 'AFI/SAFI disable' or 'session reset': > > > > * Minimum NLRI length (must be atleast 2, as key length and NLRI > > type are required fields). > > > > * Key Length MUST be at least two less than NLRI Length. > > > > Perhaps: > > Given the NLRI length and Key length MUST be valid, failures in the > > following > > checks result in 'AFI/SAFI disable' or 'session reset': > > > > * The minimum NLRI length MUST be at least 2, as key length and NLRI > > type are required fields. > > > > * The Key Length MUST be at least 2 less than NLRI Length. > > --> > > > > > > 10) <!-- [rfced] FYI, for clarity, we added the word 'steering' twice > > and changed 'path' to 'paths'. Please review whether this conveys > > this intended meaning. > > > > Original: > > All the steering variations described in [RFC9256] are applicable to BGP > > CAR color-aware path: on-demand steering, per- destination, per-flow, > > color-only steering. > > > > Current: > > All the steering variations described in [RFC9256] are applicable to BGP > > CAR color-aware paths: on-demand steering, per-destination steering, > > per-flow steering, and color-only steering. > > --> > > > > > > 11) <!-- [rfced] What is the subject of "may be shared" in the text below? > > > > Original: > > - If MPLS/SR-MPLS transport, the route will carry label/prefix- > > SID allocated by the next hop, may be shared. > > --> > > > > > > 12) <!--[rfced] Will it be clear to the reader what "color CP" and "color > > CPT" > > mean here? If not, please provide text to explain. We note that some other > > examples use "color C1" and "color C2". > > > > Current: > > * Provider publishes to customer that intent 'low-delay' is mapped > > to color CP on its inbound peering links. > > > > * Within its infrastructure, provider maps intent 'low-delay' to > > color CPT. > > --> > > > > > > 13) <!-- [rfced] FYI - Section 9: We have updated this artwork (containing > > numbered items) to to an ordered list. Please review. If you prefer to > > have the "[(V, CC)" portions aligned vertically, we can insert line > > breaks (as shown in 'Perhaps' below). For example (showing only two items): > > > > Original: > > 1. CE2 sends to PE2 : [(V, CC), Label L1] via CE2 with LCM-EC (CP) > > as per peering agreement > > 2. PE2 installs in VRF A: [(V, CC), L1] via CE2 > > which resolves on (CE2, CP) > > or connected OIF > > > > Current: > > 1. CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) as > > per peering agreement. > > > > 2. PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on > > (CE2, CP) or connected Outgoing Interface (OIF). > > > > Perhaps: > > 1. CE2 sends to PE2: > > [(V, CC), Label L1] via CE2 with LCM-EC (CP) as per peering > > agreement. > > > > 2. PE2 installs in VRF A: > > [(V, CC), L1] via CE2, which resolves on (CE2, CP) or connected > > Outgoing Interface (OIF). > > --> > > > > > > 14) <!-- [rfced] Is citing Section 9 of RFC 4364 correct here? We note > > "L3VPN" > > does not appear in RFC 4364. ("L3" appears only once in Section 14; > > zero instances of "layer 3".) > > > > Original: > > Example use-cases are intent-aware L3VPN CsC ([RFC4364] Section 9) and > > SRv6 > > over a provider network. > > > > Current: > > Example use cases are intent-aware L3VPN Carriers' Carriers (Section 9 of > > [RFC4364]) and SRv6 over a provider network. > > --> > > > > > > 15) <!-- [rfced] Appendix A.7: Is there text missing in the example below? > > For > > instance, what does "nearest" refer to? > > > > Original: > > Example-1: Anycast with forwarding to nearest > > --> > > > > > > 16) <!-- [rfced] Appendix D: We have made several updates for clarity and > > readability. Please carefully review and let us know if any additional > > updates are needed. > > > > a) FYI, we made this sentence into a list. May we change "4k bytes" > > to "4000 bytes" for clarity? (It seems fine for other instances of > > '4k' to remain in this document, as they are not followed by the word > > 'bytes'.) > > > > Original: > > Scenarios considered are ideal packing (maximum number of routes > > packed to update message limit of 4k bytes), practical deployment > > case with average packing (5 routes share set of BGP path attributes > > and hence packed in single update message) and worst-case of no > > packing (each route in separate update message). > > > > Current: > > > > The packing scenarios considered are as follows: > > > > * the ideal case (where the maximum number of routes are packed to > > the update message limit of 4k bytes), > > > > * the practical case of average packing (where 5 routes share a set > > of BGP path attributes, and hence are packed in a single update > > message), and > > > > * the worst case of no packing (where each route is in a separate > > update message). > > > > > > b) Table 5: FYI, we updated the title and made other slight adjustments to > > the table. > > > > Original: > > Figure 18: Summary of ideal, practical and no-packing BGP data in > > each case > > > > Current: > > Table 5: Summary of the Ideal, Practical, and Worst Cases of > > Packing BGP Data > > > > > > c) To avoid using an RFC number as an adjective, may we update the > > various instances of "[RFC8277] style" as follows? > > > > Original: > > > > It compares total BGP > > data on the wire for CAR SAFI and [RFC8277] style encoding in MPLS > > label (CASE A), SR extension with MPLS (per-prefix label index in > > Prefix-SID attribute) [RFC8669] (CASE B) and SRv6 SID (CASE C) cases. > > > > |RFC-8277 style | > > | NLRI | > > > > > > No degradation from RFC8277 like encoding > > > > CAR SAFI encoding more efficient by 88% in best case and 71% in average > > case over RFC8277 style encoding > > > > SAFI 128 8277 style encoding with label in NLRI > > > > Perhaps: > > > > It compares total BGP data on the wire for CAR SAFI and encoding as > > specified > > in [RFC8277] in the following: an MPLS label (CASE A), an SR extension > > with MPLS > > (per-prefix label index in Prefix-SID attribute; see [RFC8669]) (CASE B), > > and > > an SRv6 SID (CASE C). > > > > | NLRI as | > > | per RFC 8277 | > > > > No degradation from encoding as specified in [RFC8277]. > > > > CAR SAFI encoding is more efficient by 88% in the best case and 71% in the > > average case over the encoding as specified in [RFC8277] (which precludes > > packing). > > > > SAFI 128 encoded per RFC 8277 with label in NLRI > > --> > > > > > > 17) <!--[rfced] Appendix D: We suggest adding a space between the > > number and the units throughout the descriptions of Cases A, B, and C. > > Please let us know if this update is acceptable. A few examples: > > > > Original: ~86MB > > ~27.5MB > > ~339MB > > > > Suggested: ~86 MB > > ~27.5 MB > > ~339 MB > > --> > > > > > > 18) <!-- [rfced] Formatting: > > > > a) FYI, we add line breaks in the artwork so it fits within 72-character > > line > > limit. Specifically, please review the artworks in Appendices C.1, C.2, and > > C.3 titled "Packet Forwarding" and let us know if the line breaks should be > > changed. > > > > In addition, please consider whether any artwork elements should be tagged > > as > > sourcecode or a different element. > > > > > > b) Please review whether any of the notes in this document > > should be in the <aside> element. It is defined as "a container for > > content that is semantically less important or tangential to the > > content that surrounds it" > > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > --> > > > > > > 19) <!-- [rfced] FYI, we added expansions for abbreviations upon first use > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > expansion in the document carefully to ensure correctness. > > > > Autonomous Systems (ASes) > > VPN Routing and Forwarding (VRF) > > Provider Edge (PE) > > Customer Edge (CE) > > Segment Routing over MPLS (SR-MPLS) > > Label Switched Paths (LSPs) > > Network Layer Reachability Information (NLRI) > > Network Function Virtualization (NFV) > > Segment Routing Global Block (SRGB) > > Outgoing Interface (OIF) > > end-to-end (E2E) > > Longest Prefix Match (LPM) > > pseudowire (PW) > > Penultimate Segment Pop (PSP) > > --> > > > > > > 20) <!-- [rfced] Terminology: Please review the following questions we have > > regarding > > the terminology used in this document. > > > > a) We note different capitalization of the terms below. Please review and > > let > > us know each term should appear for consistency. > > > > Label Index vs. label index > > > > Label vs. label > > > > Color value vs. color value > > > > NLRI Type vs. NLRI type > > > > NLRI Length vs. NLRI length > > > > Key Length vs. Key length vs. key length > > > > > > b) "Flex Algo" appears in various forms. Please review and let us know > > how to update for consistency: > > > > Flex-Algo vs. Flex Algo vs. FlexAlgo > > > > Flex Algo 128 vs. Flex-Algo 128 vs. Flex-Algo FA128 vs. FA 128 vs. FA128 > > > > > > c) How should "prefix" be capitalized in the different instances below? > > > > BGP CAR IP Prefix routes vs. BGP CAR IP prefix route > > > > CAR IP prefix route vs. CAR IP Prefix route > > > > IP Prefix vs. IP prefix > > > > > > d) We note different use of hyphens and quotation marks in the instances > > below. How would you like these items to be stylized for consistency? > > > > low-delay vs. 'low-delay' vs. "low-delay" vs. "low delay" > > > > low-cost vs. low cost > > --> > > > > > > 21) <!-- [rfced] Terminology: We have already updated (or plan to update) > > the > > terms below for consistency. Please review and let us know any objections. > > > > a) We note different uses of the terms below. For consistency, we plan to > > update the item on the left of the arrow to the term on the right. > > > > Non-Key TLVs -> non-key TLVs > > > > multi-protocol -> multiprotocol (for consistency with RFC 4760) > > > > Label Index TLV -> Label-Index TLV (for consistency with RFC 8669) > > > > data-plane -> data plane > > > > control-plane -> control plane > > > > SR policy, SR-policy, SR-Policy -> SR Policy (for consistency with RFC 9256) > > > > > > b) The terms "border router" and "transport RR" appear throughout the > > document > > after their abbreviations "BR" and "TRR" are introduced. For consistency, > > may > > we update to use the abbreviations (after they are first introduced)? > > > > > > c) We note "Extended Community" and "Local Color Mapping" are hyphenated > > differently throughout this document (some examples below). For consistency > > with RFCs 9012 and 9256, may we update these instances to "Extended > > Community" > > and "Local Color Mapping" (no hyphens)? > > > > Local-Color-Mapping Extended-Community (LCM-EC) > > Local Color Mapping (LCM) Extended Community > > Local Color Mapping Extended-Community > > > > Route Target (RT) Extended-Communities > > Transitive Opaque Extended-Community > > BGP Extended-Community > > > > > > d) FYI - We have already updated the terms below as follows for consistency > > with their relevant RFCs. > > > > RT-Constrain -> RT Constrain (per RFC 4684) > > Prefix-SID Attribute -> Prefix-SID attribute (per RFC 8669) > > BGP Prefix-SID Attribute -> BGP Prefix-SID attribute (per RFC 8669) > > SRv6 service SID -> SRv6 Service SID (per RFC 9252) > > SR Domain -> SR domain (per RFC 8402) > > END behavior -> End behavior (per RFC 8986) > > Route Target (RT) Extended-Communities -> Route Target (RT) Extended > > Communities (per RFC 4360) > > AIGP Attribute -> AIGP attribute (per RFC 7311) > > > > e) Is the term "CAR color-aware path" (3 instances) necessary, or should > > it simply be "CAR path" (10 instances)? > > > > Section 1.2 > > - V/v is steered on BGP CAR color-aware path > > - V/v is steered on a BGP CAR color-aware path that is itself ... > > > > Section 3: > > All the steering variations described in [RFC9256] are > > applicable to BGP CAR color-aware paths: on-demand steering, ... > > --> > > > > > > 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. > > > > a) For example, please consider whether "native" should be updated in the > > instances below: > > > > Section 2.7. Native MultiPath Capability > > > > Native support for multiple transport encapsulations (e.g., MPLS, SR, > > SRv6, IP) > > > > Native encoding of SIDs avoids robustness issue... > > > > Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is > > natively > > steered hop by hop along IPv6 routed path... > > > > Encapsulated service traffic is natively steered along IPv6 routed path... > > > > > > b) In addition, please consider whether "traditional" should be updated for > > clarity. > > While the NIST website > > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > > indicates that this term is potentially biased, it is also ambiguous. > > "Tradition" is a subjective term, as it is not the same for everyone. > > There are 4 instances currently: > > > > If a color-aware path is not > > available, local policy may map to a traditional routing/TE > > path (e.g., BGP LU, RSVP-TE, IGP/LDP). > > > > Intra-domain resolution: > > BGP CAR route maps to an intra-domain color-aware path (e.g., > > SR Policy, IGP Flex-Algo, BGP CAR) or a traditional routing/TE > > path (e.g., RSVP-TE, IGP/LDP, BGP-LU). > > > > * Local policy may map the CAR route to traditional mechanisms that > > are unaware of color or that provide best-effort, such as RSVP-TE, > > IGP/LDP, BGP LU/IP (e.g., Appendix A.3.2) for brownfield > > scenarios. > > > > However, to be compatible > > with traditional operational usage, the CAR IP Prefix route is > > allowed to be without color for best-effort. > > --> > > > > > > Thank you. > > > > Kaelin Foody and Alice Russo > > RFC Production Center > > > > > > On Sep 25, 2025, [email protected] wrote: > > > > *****IMPORTANT***** > > > > Updated 2025/09/25 > > > > RFC Author(s): > > -------------- > > > > Instructions for Completing AUTH48 > > > > Your document has now entered AUTH48. Once it has been reviewed and > > approved by you and all coauthors, it will be published as an RFC. > > If an author is no longer available, there are several remedies > > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > You and you coauthors are responsible for engaging other parties > > (e.g., Contributors or Working Group) as necessary before providing > > your approval. > > > > Planning your review > > --------------------- > > > > Please review the following aspects of your document: > > > > * RFC Editor questions > > > > Please review and resolve any questions raised by the RFC Editor > > that have been included in the XML file as comments marked as > > follows: > > > > <!-- [rfced] ... --> > > > > These questions will also be sent in a subsequent email. > > > > * Changes submitted by coauthors > > > > Please ensure that you review any changes submitted by your > > coauthors. We assume that if you do not speak up that you > > agree to changes submitted by your coauthors. > > > > * Content > > > > Please review the full content of the document, as this cannot > > change once the RFC is published. Please pay particular attention to: > > - IANA considerations updates (if applicable) > > - contact information > > - references > > > > * Copyright notices and legends > > > > Please review the copyright notice and legends as defined in > > RFC 5378 and the Trust Legal Provisions > > (TLP – https://trustee.ietf.org/license-info). > > > > * Semantic markup > > > > Please review the markup in the XML file to ensure that elements of > > content are correctly tagged. For example, ensure that <sourcecode> > > and <artwork> are set correctly. See details at > > <https://authors.ietf.org/rfcxml-vocabulary>. > > > > * Formatted output > > > > Please review the PDF, HTML, and TXT files to ensure that the > > formatted output, as generated from the markup in the XML file, is > > reasonable. Please note that the TXT will have formatting > > limitations compared to the PDF and HTML. > > > > > > Submitting changes > > ------------------ > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > > the parties CCed on this message need to see your changes. The parties > > include: > > > > * your coauthors > > > > * [email protected] (the RPC team) > > > > * other document participants, depending on the stream (e.g., > > IETF Stream participants are your working group chairs, the > > responsible ADs, and the document shepherd). > > > > * [email protected], which is a new archival mailing list > > to preserve AUTH48 conversations; it is not an active discussion > > list: > > > > * More info: > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-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, > > [email protected] will be re-added to the CC list and > > its addition will be noted at the top of the message. > > > > You may submit your changes in one of two ways: > > > > An update to the provided XML file > > — OR — > > An explicit list of changes in this format > > > > Section # (or indicate Global) > > > > OLD: > > old text > > > > NEW: > > new text > > > > You do not need to reply with both an updated XML file and an explicit > > list of changes, as either form is sufficient. > > > > We will ask a stream manager to review and approve any changes that seem > > beyond editorial in nature, e.g., addition of new text, deletion of text, > > and technical changes. Information about stream managers can be found in > > the FAQ. Editorial changes do not require approval from a stream manager. > > > > > > Approving for publication > > -------------------------- > > > > To approve your RFC for publication, please reply to this email stating > > that you approve this RFC for publication. Please use ‘REPLY ALL’, > > as all the parties CCed on this message need to see your approval. > > > > > > Files > > ----- > > > > The files are available here: > > https://www.rfc-editor.org/authors/rfc9871.xml > > https://www.rfc-editor.org/authors/rfc9871.html > > https://www.rfc-editor.org/authors/rfc9871.pdf > > https://www.rfc-editor.org/authors/rfc9871.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9871-diff.html > > https://www.rfc-editor.org/authors/rfc9871-rfcdiff.html (side by side) > > > > This diff file uses an altered original to show the changes in > > Section 1.1 and the moved text (Acknowledgements and Contributors): > > https://www.rfc-editor.org/authors/rfc9871-alt-diff.html > > > > Diff of the XML: > > https://www.rfc-editor.org/authors/rfc9871-xmldiff1.html > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9871 > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC9871 (draft-ietf-idr-bgp-car-16) > > > > Title : BGP Color-Aware Routing (CAR) > > Author(s) : D. Rao, Ed., S. Agrawal, Ed. > > WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
