IANA, Please update the SAFI Values registry at https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml as follows to match the document.
Original: Value: 76 Description: Classful Transport SAFI New: Value: 76 Description: Classful Transport (CT) Please confirm when this update is complete and/or let us (and the authors) know any questions/concerns. Thank you. RFC Editor/mf > On Aug 27, 2025, at 4:03 PM, Natrajan Venkataraman <n...@juniper.net> wrote: > > Hi Megan, > > I have reviewed the comprehensive diff after internal discussions with > Kaliraj and Reshma. I would like to extend my thanks to you and the AUTH48 > team for suggesting these changes. These changes have improved the > readability of this draft quite extensively with fewer abbreviations and > consistent usage of new definitions that aid the overall flow. > > Very Pleased and Thank You, > Nats. > > > Juniper Business Use Only > > From: Kaliraj Vairavakkalai <kali...@juniper.net> > Date: Wednesday, August 27, 2025 at 2:47 PM > To: Megan Ferguson <mfergu...@staff.rfc-editor.org>, Jeffrey Haas > <jh...@pfrc.org> > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Natrajan > Venkataraman <n...@juniper.net>, idr-...@ietf.org<idr-...@ietf.org>, > idr-cha...@ietf.org <idr-cha...@ietf.org>, Sue Hares <sha...@ndzh.com>, John > Scudder <j...@juniper.net>, > auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>, Reshma Das > <dres...@juniper.net>, > draft-ietf-idr-bgp-ct.not...@ietf.org<draft-ietf-idr-bgp-ct.not...@ietf.org> > Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your review > > Hi Megan, > > >> We have adopted this version with only a few slight tweaks (e.g., the > >> title of Section 6.3 has been changed to use “Multiple Types” to match the > >> change in paragraph 1 of that section). Please review and let us know if > >> any further changes are necessary. > > I am good with the changes. > > Thanks > Kaliraj > > > Juniper Business Use Only > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Date: Wednesday, August 27, 2025 at 9:19 AM > To: Jeffrey Haas <jh...@pfrc.org> > Cc: Kaliraj Vairavakkalai <kali...@juniper.net>, rfc-edi...@rfc-editor.org > <rfc-edi...@rfc-editor.org>, Natrajan Venkataraman <n...@juniper.net>, > idr-...@ietf.org <idr-...@ietf.org>, > idr-cha...@ietf.org<idr-cha...@ietf.org>, Sue Hares <sha...@ndzh.com>, John > Scudder <j...@juniper.net>, auth48archive@rfc-editor.org > <auth48archive@rfc-editor.org>, Reshma Das <dres...@juniper.net>, > draft-ietf-idr-bgp-ct.not...@ietf.org <draft-ietf-idr-bgp-ct.not...@ietf.org> > Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your review > > [External Email. Be cautious of content] > > > Hi Jeff, > > Great question. > > Generally, the RPC strives for consistency (to the extent possible): > 1) within a doc > 2) within a cluster > 3) within the series > > We also (generally) suggest less marking of terms (capping, quoting, > hyphenating, using <tt> tags, etc.) whenever possible as these are difficult > to keep consistent over time and can even be distracting/confusing to the > reader if overused or inconsistently applied. > > Because of previous mixed use in RFCs for the term in question, we went with > the guidance we received from the authors of RFC-to-be 9830 (see the cluster > page > herehttps://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C534__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OmZiXBOw$ > for a list of those authors). > > If you feel this is in error or are considering using the capped form in the > possible future -bis and are hoping these docs will match up, please feel > free to discuss with the authors of this document (and the related cluster > docs) and let us know if changes are necessary/desired. > > Please let us know if we can be of further assistance on this matter. > > Megan Ferguson > RPC Production Center > > > > On Aug 27, 2025, at 6:44 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > > > > Megan, > > > > I had one question while reviewing the changes from the editors. This is > > prompted by work in IDR to do a -bis on RFC 4360, for extended communities. > > > > RFC 4360 is itself not terribly consistent about the use of the > > capitalization of the feature. In a significant portion of the document, > > it is labeled "Extended Community" when used in a proper noun context. > > > > In the diff for -ct, it has been consistently lower-cased. > > > > What's the thinking here, and how much of this is tied specifically to RFC > > 4360 itself? > > > > -- Jeff > > > > > >> On Aug 26, 2025, at 7:03 PM, Megan Ferguson > >> <mfergu...@staff.rfc-editor.org> wrote: > >> > >> Hi Kaliraj, > >> > >> Thank you for updating the file and your guidance. > >> > >> We have adopted this version with only a few slight tweaks (e.g., the > >> title of Section 6.3 has been changed to use “Multiple Types” to match the > >> change in paragraph 1 of that section). Please review and let us know if > >> any further changes are necessary. > >> > >> Once we receive approvals of this version from both authors, we will > >> communicate changes that affect the related IANA registries (i.e., the > >> change in Table 1) to IANA prior to moving forward in the publication > >> process. Note that this document will also await the completion of AUTH48 > >> for the other documents in Cluster C 534 (see below). > >> > >> Please be sure to review the files carefully as we do not make changes > >> once the document is published as an RFC. > >> > >> The files have been posted here (please refresh): > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.txt__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1Og1erqnp$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.pdf__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OsHPrJ91$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OmpW_MC0$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OlfxcXC-$ > >> > >> The relevant diff files have been posted here (please refresh): > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-diff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OiD6pEI8$ > >> (comprehensive) > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-rfcdiff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OiMQMkSR$ > >> (side by side) > >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-auth48diff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OlbhPs7C$ > >> (AUTH48 changes only) > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-auth48rfcdiff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OqnflwE8$ > >> (side by side) > >> > >> The AUTH48 status page for this document can be found here: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9832__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1Oryt4ZjY$ > >> > >> The relevant cluster information can be found here: > >> https://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C534__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OmZiXBOw$ > >> > >> > >> Thank you. > >> > >> Megan Ferguson > >> RFC Production Center > >> > >> > >> > >> > >>> On Aug 22, 2025, at 5:39 PM, Kaliraj Vairavakkalai > >>> <kaliraj=40juniper....@dmarc.ietf.org> wrote: > >>> > >>> Hi RFC-ed, > >>> > >>> I made another git push with changes to address some pending warnings > >>> like “Artwork too wide”. > >>> > >>> Please git pull, same location: > >>> https://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OjkbE0cp$ > >>> > >>> Thanks > >>> Kaliraj > >>> > >>> Juniper Business Use Only > >>> > >>> From: Kaliraj Vairavakkalai <kali...@juniper.net> > >>> Date: Friday, August 22, 2025 at 2:04 AM > >>> To: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Natrajan > >>> Venkataraman <n...@juniper.net> > >>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > >>> idr-...@ietf.org <idr-...@ietf.org>, idr-cha...@ietf.org > >>> <idr-cha...@ietf.org>, sha...@ndzh.com<sha...@ndzh.com>, John Scudder > >>> <j...@juniper.net>, > >>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>, Reshma Das > >>> <dres...@juniper.net>, > >>> draft-ietf-idr-bgp-ct.not...@ietf.org<draft-ietf-idr-bgp-ct.not...@ietf.org> > >>> Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > >>> review > >>> > >>> Hi RFC-ed, > >>> > >>> We went thru the comments and incorporated them. Accepted most of them. > >>> > >>> For some of the comments, I have left responses in the xml under the > >>> <rfced> tag, with the prefix KV> > >>> > >>> Please go thru the revised document and let us know. > >>> > >>> Here is the link to the updated xml in github: > >>> > >>> https://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/369e32c114263e81a02fb556f80c765daa8b7927/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OstcI15X$ > >>> > >>> Thanks > >>> Kaliraj > >>> > >>> From: Kaliraj Vairavakkalai <kali...@juniper.net> > >>> Date: Wednesday, August 20, 2025 at 1:47 AM > >>> To: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Natrajan > >>> Venkataraman <n...@juniper.net> > >>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > >>> idr-...@ietf.org<idr-...@ietf.org>, idr-cha...@ietf.org > >>> <idr-cha...@ietf.org>, sha...@ndzh.com<sha...@ndzh.com>, John Scudder > >>> <j...@juniper.net>, auth48archive@rfc-editor.org > >>> <auth48archive@rfc-editor.org>, Reshma Das <dres...@juniper.net>, > >>> draft-ietf-idr-bgp-ct.not...@ietf.org > >>> <draft-ietf-idr-bgp-ct.not...@ietf.org> > >>> Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > >>> review > >>> > >>> Hi RFC-Editor, thanks for the update. Cc: coauthors notify alias. > >>> > >>> We’ll go thru the comments and update the xml, as appropriate. > >>> > >>> I added the xml to github > >>> (https://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OjkbE0cp$ > >>> ), before making any updates. > >>> > >>> Thanks > >>> Kaliraj > >>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >>> Date: Tuesday, August 19, 2025 at 7:33 PM > >>> To: Kaliraj Vairavakkalai <kali...@juniper.net>, Natrajan Venkataraman > >>> <n...@juniper.net> > >>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > >>> idr-...@ietf.org <idr-...@ietf.org>, idr-cha...@ietf.org > >>> <idr-cha...@ietf.org>, sha...@ndzh.com<sha...@ndzh.com>, John Scudder > >>> <j...@juniper.net>, > >>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > >>> Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > >>> review > >>> > >>> [External Email. Be cautious of content] > >>> > >>> > >>> Authors, > >>> > >>> While reviewing this document during AUTH48, please resolve (as > >>> necessary) the following questions, which are also in the XML file. > >>> > >>> NOTE: For this document in particular, we request that the authors > >>> consider updating the edited XML file > >>> (https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.xml__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZoweX5uA$ > >>> ) directly as there are a number of instances in which it may be easier > >>> for them to do so than to explain the changes to the RPC (and may save > >>> iterations for both sides). > >>> > >>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>> the title) for use on > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZupPNXMg$ > >>> . --> > >>> > >>> > >>> 2) <!--[rfced] We see mention of the "TEAs Network Slices Framework" in > >>> the Abstract, may we update as follows to clarify the document > >>> you are mentioning? > >>> > >>> Original: > >>> These constructs can be used, for example, to realize the "IETF > >>> Network Slice" defined in TEAS Network Slices framework. > >>> > >>> > >>> Perhaps: > >>> These constructs can be used, for example, to realize the "IETF > >>> Network Slice" defined in the TEAS Network Slices framework (RFC > >>> 9543). > >>> > >>> --> > >>> > >>> > >>> 3) <!--[rfced] In the following text snippets, please review the format > >>> of attributes for the following: > >>> > >>> a) Should all of these names be in all caps (for example, code 25 is > >>> in initial caps while code 8 is in all caps)? > >>> > >>> b) Should they all use "attribute type code", "BGP attribute code", or > >>> "attribute code" in their parentheticals? Or are these purposely > >>> different? > >>> > >>> Original: > >>> A BGP attribute that carries community. Examples of BGP CCAs are > >>> COMMUNITIES (attribute code 8), EXTENDED COMMUNITIES (attribute code > >>> 16), IPv6 Address Specific Extended Community (attribute code 25), and > >>> LARGE_COMMUNITY (attribute code 32). > >>> > >>> ... > >>> > >>> TEA: Tunnel Encapsulation Attribute (attribute type code 23) > >>> > >>> ... > >>> > >>> It is carried in BGP extended community attribute (BGP attribute code > >>> 16). > >>> > >>> ... > >>> > >>> ..., or IPv6-address specific RT (BGP attribute code 25). > >>> > >>> ... > >>> > >>> ...UDP tunneling information is carried using the Tunnel Encapsulation > >>> Attribute (code 23)... > >>> > >>> --> > >>> > >>> > >>> 4) <!--[rfced] Please review the use of "color field" in the following > >>> text and let us know if it should instead be "Color Value field" > >>> to match the use in RFC 9012. (Note that the quotations around > >>> field names depend on your response to that related question.) > >>> > >>> Original: > >>> > >>> ...with the Flags field set to 0 and the color field set to 100. > >>> > >>> > >>> Perhaps: > >>> ...with the "Flags" field set to 0 and the "Color Value" field set to 100. > >>> --> > >>> > >>> > >>> 5) <!--[rfced] Regarding figures, artwork, and SVG: > >>> > >>> a) Please review that all lines in <artwork> are 69 characters or > >>> less. If not, please consider how figures may be updated in order to > >>> fit this limitation (some warnings of outdenting from xml2rfc exist). > >>> > >>> b) FYI - the RPC does not edit SVG figures. If any changes are made > >>> to their ASCII equivalents, authors should incorporate these changes > >>> into the SVG and resubmit these changes to the RPC. > >>> > >>> > >>> --> > >>> > >>> > >>> 6) <!-- [rfced] We had a few questions related to the text below: > >>> > >>> a) We note that [RFC4360] doesn't appear to use the term "EXT-COMM". > >>> Please review the following citation for accuracy. > >>> > >>> b) Please also review this text for redundancy and let us know if/how > >>> this text may be rephrased (we have already removed the EXT-COMM > >>> link). > >>> > >>> Current: > >>> The "Transport Class" Route Target Extended Community is a transitive > >>> extended community [RFC4360] of extended type, which has the > >>> format as shown in Figure 2. > >>> --> > >>> > >>> > >>> 7) <!--[rfced] Should the names in the following paragraph (and anywhere > >>> they are mentioned throughout the document) be made more uniform > >>> (i.e., should Route Target be added to the first use of "extended > >>> community")? See a later question related to the quotation use > >>> as well. > >>> > >>> Original: > >>> This document also reserves the Non-Transitive version of Transport > >>> Class extended community (Section 13.2.1.1.2) for future use. The > >>> "Non-Transitive Transport Class" Route Target Extended Community is > >>> not used. If received, it is considered equivalent in functionality > >>> to the Transitive Transport Class Route Target Extended Community, > >>> except for the difference in Transitive bit flag. > >>> > >>> Perhaps: > >>> This document also reserves the Non-Transitive version of the Transport > >>> Class Route Target extended community (Section 13.2.1.1.2) for future > >>> use. The > >>> Non-Transitive Transport Class Route Target extended community is > >>> not used. If received, it is considered equivalent in functionality > >>> to the Transitive Transport Class Route Target extended community, > >>> except for the difference in the Transitive bit flag. > >>> --> > >>> > >>> > >>> 8) <!-- [rfced] We note that "color:0:100" isn't used in [RFC9012]. It's > >>> defined in this document (See Section 2.1. Definitions and > >>> Notations). Please review the citation in the following text for > >>> accuracy (or need of a possible rewording). > >>> > >>> Current: > >>> > >>> An example of mapping community is "color:0:100", described in > >>> [RFC9012], or the "transport-target:0:100" described in Section 4.3 in > >>> this document. > >>> > >>> --> > >>> > >>> > >>> 9) <!--[rfced] If our addition of "exist" does not capture your > >>> intent, please review the original text and suggest > >>> another rephrase. > >>> > >>> Original: > >>> If more than one distinct Mapping Communities on an overlay route map > >>> to distinct Resolution Schemes with dissimilar Intents at a receiving > >>> node, it is considered a configuration error. > >>> > >>> Perhaps: > >>> If more than one distinct Mapping Community on an overlay route map > >>> to distinct Resolution Schemes with dissimilar Intents at a receiving > >>> node exist, it is considered a configuration error. > >>> --> > >>> > >>> > >>> 10) <!--[rfced] Because "information" is a noncount noun, it would be > >>> unusual to say "multiple information". How may we update? > >>> Perhaps "Multiple Types of Encapsulation Information"? > >>> > >>> > >>> Original: > >>> 6.3. Carrying multiple Encapsulation Information > >>> > >>> and > >>> > >>> ...route allows carrying multiple encapsulation information. > >>> > >>> --> > >>> > >>> > >>> 11) <!-- [rfced] We note that Section 3 of [RFC8669] uses "Prefix-SID" > >>> rather than "Prefix SID". May we update to make these > >>> consistent? > >>> > >>> Current: > >>> > >>> The SID information for SR with respect to MPLS Data Plane is carried > >>> as specified in Prefix SID attribute defined as part of Section 3 of > >>> [RFC8669]. > >>> > >>> --> > >>> > >>> > >>> 12) <!--[rfced] Please review our updates to the text below and confirm > >>> that we have interpreted your list correctly (i.e., the BGP CT > >>> route is originated with RD:EP in the NLRI along with a Transport > >>> Class RT, and the endpoint being a protocol next hop). If this > >>> is not the intent, please provide another rephrase. > >>> > >>> Original: > >>> The egress node of the tunnel, i.e. the tunnel endpoint (EP), > >>> originates the BGP CT route with RD:EP in the NLRI, Transport Class RT > >>> and PNH as EP. > >>> > >>> Current: > >>> > >>> The egress node of the tunnel, i.e., the tunnel endpoint (EP), > >>> originates the BGP CT route with RD:EP in the NLRI, a Transport Class > >>> RT, and a PNH as the EP. > >>> > >>> > >>> --> > >>> > >>> > >>> 13) <!-- [rfced] Please confirm the following citation as [RFC9350] > >>> doesn't appear to use the term "ISIS Flex-Algo" (we note that it > >>> does contain the term "Flex-Algorithm"). > >>> > >>> Current: > >>> > >>> AS2 is further divided into two regions. There are three tunnel > >>> domains in provider's space: AS1 uses ISIS Flex-Algo [RFC9350] > >>> intra-domain tunnels. AS2 uses RSVP-TE intra-domain tunnels. > >>> > >>> --> > >>> > >>> > >>> 14) <!--[rfced] Please review the use of a comma in the following > >>> situations: > >>> > >>> a) Between "1" and "128" in the following. We have seen 1/128 in the > >>> earlier parts of this document: are these different meanings? This > >>> occurs in more than one place. > >>> > >>> Original: > >>> > >>> Service nodes PE11, PE12 negotiate service families (AFI: 1 and SAFIs > >>> 1, 128) on the BGP session with RR16. > >>> > >>> b) Throughout Section 8.3 and elsewhere in the document, we replaced > >>> many commas with "and" as we believe this was the intended meaning. > >>> Please review and let us know any objections. > >>> --> > >>> > >>> > >>> 15) <!--[rfced] We note that this document uses TC ID to refer to a > >>> Transport Class Identifier in the Terminology section. Please > >>> review the use of TC (without ID) in the text below where it > >>> seems the expansion is "Transport Class identifier" and let us > >>> know if/how to update. > >>> > >>> Original: > >>> ...transport-target:0:<TC> and a RT carrying <eSN>:<TC>, where TC is > >>> the Transport Class identifier, and eSN is the IP address used by SN > >>> as BGP next hop in its service route advertisements. > >>> > >>> --> > >>> > >>> > >>> 16) <!--[rfced] We see the following similar sentences in back-to-back > >>> paragraphs. Please review and let us know if/how we can reduce > >>> redundancy. > >>> > >>> Original: > >>> > >>> This is possible using mechanism described in Appendix D, such that > >>> advertisement of PE loopback addresses as next-hop in BGP service > >>> routes is confined to the region they belong to. An anycast > >>> IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts > >>> the SNs in a region from other regions in the network. > >>> > >>> Such that advertisement of PE loopback addresses as next-hop in BGP > >>> service routes is confined to the region they belong to. An anycast > >>> IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts > >>> the SNs in a region from other regions in the network. > >>> > >>> > >>> --> > >>> > >>> > >>> 17) <!--[rfced] We had the following questions related to the IANA > >>> Considerations section: > >>> > >>> > >>> a) We would like to make sure we understand the structure of the IANA > >>> Considerations section. Currently, we see: > >>> > >>> 13.1 and 13.2 - seem to add values to existing registries with some > >>> duplication to later sections (see question c below) > >>> > >>> 13.2.1-13.2.1.1.2 - all under a heading of "Existing Registries" > >>> > >>> 13.2.2 - 13.2.2 All under a heading of "New Registries" > >>> > >>> 13.3 - Adds two code points to an existing registry > >>> > >>> > >>> Perhaps we could update to something structured along the lines of > >>> updates to existing registries and creation of new ones? > >>> > >>> 13. IANA Considerations > >>> 13.1. Existing Registries > >>> 13.1.1. New BGP SAFI > >>> 13.1.2. New Format for BGP Extended Community > >>> 13.1.3. Registries for the "Type" Field > >>> 13.1.3.1. Transitive Types > >>> 13.1.3.2. Non-Transitive Types > >>> 13.1.4. MPLS OAM Code Points > >>> 13.2. New Registries > >>> 13.2.1. Transitive Transport Class Extended Community Sub-Types Registry > >>> 13.2.2. Non-Transitive Transport Class Extended Community Sub-Types > >>> Registry > >>> > >>> > >>> With something like the following text in Section 13 itself to > >>> introduce the actions: > >>> > >>> This document registers values in existing registries and creates new > >>> registries as described in the following subsections. > >>> > >>> NOTE: Please review our question c) below before responding. > >>> > >>> Please let us know if this restructuring would be agreeable. > >>> > >>> b) Please note that we have updated the capitalization (to lowercase) > >>> of the values in Tables 4 and 6 to match the use in the corresponding > >>> IANA registries. Please review and let us know any objections. > >>> > >>> c) Section 13.2 made us expect that 0xa would be registered in both > >>> the "BGP Transitive Extended Community Types" registry and the "BGP > >>> Non-Transitive Extended Community Types" registry. > >>> > >>> However, we do not see a registration of 0xa in the "BGP > >>> Non-Transitive Extended Community Types" registry at > >>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml*non-transitive__;Iw!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZgtmHNek$ > >>> . > >>> > >>> We do see an entry for "0x4a" for "Non-Transitive Transport Class", > >>> that is mentioned in the current Section 13.2.1.1.2. > >>> > >>> Please review this section for accuracy and redundancy with Sections > >>> 13.2.1.1.1 and 13.2.1.1.2 and let us know if/how we may update (or if > >>> we are just missing something on our end?). > >>> > >>> d) Section 13.2 says: > >>> > >>> Taking reference of [RFC7153] , the following assignments have been > >>> made: > >>> > >>> As none of the new entries in the registries list RFC 7153 as a > >>> reference themselves, should this text instead read: > >>> > >>> The registries below each reference RFC 7153. > >>> > >>> Or is there another way to rephrase? > >>> > >>> e) FYI - Any updates made to text that appears in IANA registries will > >>> be communicated by the RPC to IANA upon the completion of AUTH48. > >>> > >>> --> > >>> > >>> > >>> 18) <!--[rfced] As Section 14.1 (Transport Class ID) is no longer in > >>> the IANA Considerations sections, we have made some updates > >>> to help the reader. Please review this section carefully > >>> and let us know any concerns. --> > >>> > >>> > >>> 19) <!--[rfced] We note that the reference to > >>> draft-kaliraj-bess-bgp-sig-private-mpls-labels-09 has been > >>> replaced by draft-kaliraj-bess-bgp-mpls-namespaces. Please > >>> review this reference entry / citation and let us know if/how > >>> updates should be made.--> > >>> > >>> > >>> 20) <!--[rfced] The citation tag [BGP-CT-UPDATE-PACKING-TEST] is a bit > >>> long. Might we update to something shorter?--> > >>> > >>> > >>> 21) <!--[rfced] Please note that we have slightly modified the format of > >>> the Contributors section to make it more similar to the use in > >>> past RFCs and the guidance of RFC 7322 ("RFC Style Guide"). > >>> Please let us know any objections.--> > >>> > >>> > >>> 22) <!--[rfced] We had the following questions/comments related to > >>> abbreviation use throughout the document: > >>> > >>> a) Abbreviations that appeared without expansion have been expanded > >>> upon first use following guidance from RFC 7322 ("RFC Style Guide"). > >>> Please review these expansions for accuracy. > >>> > >>> b) We made some updates to the list of abbreviations in the Terminology > >>> section to match their use in past RFCs. We also flipped the > >>> expansion of TC-BE for a better 1:1 match between the abbreviation and > >>> the expansion. Please review carefully and let us know any > >>> objections. > >>> > >>> c) We see BN expanded as "Border Node". Past use in RFCs points to > >>> "Boundary Node". Please review and let us know if any updates should > >>> be made. > >>> > >>> d) The term "Labeled ISIS" and the abbreviation "L-ISIS" don't appear > >>> in RFC 8867, and RFC 8867 does not appear in the References section of > >>> this document. Please review the citation to this RFC in the > >>> Terminology section and let us know if/how to update. > >>> > >>> e) [RFC4684] uses "Route Target (RT) Constrain" rather than "Route > >>> Target Constrain (RTC)". We do see "Route Target Constraint (RTC)" in > >>> RFC 9125 (when citing RFC 4684). Please let us know if we should adopt > >>> the same form here (i.e., Route Target Constraint (RTC)). > >>> > >>> > >>> f) TC is expanded as Traffic Class in the companion documents > >>> (RFCs-to-be 9830 and 9831). This document expands it as Transport > >>> Class. Please review and let us know if we should make this > >>> consistent (see also TC ID and TC-BE). > >>> > >>> g) To follow the guidance at > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*exp_abbrev__;Iw!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZkxxo_JU$ > >>> , we will > >>> update to have the following abbreviations expanded on first use and > >>> then use the abbreviated form thereafter unless we hear objection: > >>> > >>> Transport Class (TC) > >>> Route Target (RT) > >>> Route Target Constrain (RTC) (see related query above) > >>> Community Carrying Attribute (CCA) > >>> BGP Classful Transport (BGP CT) > >>> Address Family Identifier (AFI) > >>> Route Distinguisher (RD) > >>> Endpoint (EP) > >>> Next Hop (NH) > >>> Transport Route Database (TRDB) > >>> Ingress Service Node (iSN) > >>> Egress Service Node (eSN) > >>> Autonomous System (AS) > >>> Per-Hop Behavior (PHB) > >>> > >>> --> > >>> > >>> > >>> 23) <!--[rfced] We had the following questions related to terminology > >>> used throughout the document: > >>> > >>> a) Please note that we updated to use the following forms with relation > >>> to capitalization, hyphenation, etc. to match use/guidance in other > >>> documents in this cluster (see > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C534__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlogh6yX$ > >>> ). Please review > >>> and let us know any objections: > >>> > >>> BGP UPDATE message > >>> Color Extended Community > >>> Route Target extended community > >>> data plane > >>> > >>> Please review the different treatment of "Extended Community" > >>> vs. "extended community" and confirm that this difference is > >>> intentional. > >>> > >>> b) Keeping point a) in mind, please review the names of the > >>> communities and extended communities throughout the document for > >>> consistency. We see varied use of quotation marks, places where words > >>> may be missing, differences in capitalization, etc. Examples below: > >>> > >>> Transport Class Route Target extended community vs. Transport Class > >>> extended community vs. "Transport Class" extended community (see also > >>> Transport Class Route Target vs. transport-class route-target) > >>> > >>> Transport Target Extended community > >>> > >>> transitive extended community vs. Transitive Extended Community > >>> > >>> Non-Transitive Extended Community vs. "Non-Transitive Transport Class" > >>> Route Target extended community vs. Non-Transitive Transport Class > >>> Extended community vs. "Non-Transitive Transport Class route target > >>> extended community" vs. Non-Transitive Transport Class vs. > >>> Non-Transitive version of the Transport Class extended community > >>> > >>> Mapping Community vs. Mapping community vs. mapping community > >>> > >>> Community vs. community (when used alone; see also communities) > >>> > >>> Extended Community vs. extended community (when used alone; see also > >>> extended communities) > >>> > >>> > >>> c) The following terminology seems to use inconsistent marking (i.e., > >>> capitalization, hyphenation, etc.) throughout the document. Please > >>> review these instances and consider if/how they may be made uniform: > >>> > >>> Resolution Scheme vs. resolution scheme vs. "Resolution Scheme" > >>> > >>> Route Target vs. route target > >>> > >>> Ingress domain vs. ingress domain > >>> > >>> Ingress node vs. ingress node > >>> > >>> Ingress PE vs. ingress PE (see also egress) > >>> > >>> Intent vs. intent > >>> > >>> Inter-AS vs. inter-AS (and Intra-AS vs. intra-AS) > >>> > >>> Option C vs. option c (and others like option b etc.) > >>> > >>> BGP Classful Transport vs. Classful Transport > >>> > >>> Classful Transport BGP route vs. Classful Transport route vs. BGP > >>> Classful Transport family routes > >>> > >>> Classful Transport NLRI vs. Classful Transport NLRI Prefix > >>> vs. Classful Transport prefix vs. "Classful Transport" SAFI NLRI > >>> > >>> Transport Tunnels vs. transport tunnels > >>> > >>> Transport-target vs. transport-target > >>> > >>> transport-target:0:100 vs. transport route target 0:200 vs. route > >>> target "transport-target:0:100" vs. transport class 100 routes > >>> > >>> Transport Family vs. Transport family vs. transport family (see also > >>> families) > >>> > >>> Transport class vs. transport class vs. Transport Class > >>> > >>> "Transport Class ID" field vs. "Transport Class" identifier > >>> > >>> Transport Class ID 100 vs. Transport Class 100 > >>> > >>> Color vs. color vs. 'Color' vs. "Color" (FYI 9830 is using Color) > >>> > >>> color:0:100500 vs. Color:0:100 > >>> > >>> Transposition scheme vs. transposition scheme vs. Transposition Scheme > >>> > >>> operator vs. Operator > >>> > >>> service family vs. Service family > >>> > >>> service route vs. Service route > >>> > >>> FLEX-ALGO vs. Flex-Algo vs. FlexAlgo > >>> > >>> MPLS label vs. MPLS Label > >>> > >>> Implicit-NULL vs. Implicit Null vs. Implicit NULL > >>> > >>> special label 3 (Implicit NULL) vs. value 3 (Implicit-NULL) > >>> > >>> RD:EP vs. "RD:EP" vs. 'RD:Endpoint' vs. "RD:Endpoint" vs. RD,EP > >>> vs. "RD, EP" (see also RD, RT) > >>> > >>> gold vs. Gold > >>> > >>> bronze vs. Bronze > >>> > >>> d) Terms including "best effort": we have updated these terms to > >>> appear as hyphenated when in attributive position (modifying a noun) > >>> but left them open otherwise. However, there is variance related to > >>> their quotation, capitalization, etc. remaining. Please review the > >>> terms and let us know if/how further updates for uniformity may be > >>> made (note: the list below includes our hyphenation changes). > >>> > >>> best-effort transport class vs. Best-Effort Transport Class > >>> > >>> "Best-Effort" transport class TRDB vs. Best-Effort TRDB vs. TRDB for best > >>> effort > >>> > >>> "best-effort" transport class routes vs. best-effort transport route > >>> > >>> 'Best-effort' SLA vs. best-effort SLA > >>> > >>> "Best-Effort Transport Class Route Target" vs. Best-Effort Transport > >>> Class Route Target > >>> > >>> "Best-Effort" Resolution Scheme vs. Best-effort resolution scheme vs. > >>> best-effort resolution scheme > >>> > >>> > >>> > >>> e) Please review the following similar instances and let us know > >>> if/how they should be made uniform. > >>> > >>> SAFI 76 (BGP CT) > >>> SAFI 76 "Classful Transport" > >>> AFI/SAFI 1/76 (Classful Transport SAFI) > >>> > >>> AFI/SAFI 1/128 (MPLS-labeled VPN address) > >>> Inet-VPN SAFI 128 > >>> SAFI 128 (L3VPN) > >>> > >>> f) There are many places in which quotation marks are used that we are > >>> uncertain of their meaning/purpose and they are inconsistent > >>> (appearing sometimes and not others or single quotes in some places > >>> while double or no quotes in others). > >>> > >>> Please review the use of quotation marks generally throughout the > >>> document. We suggest removing quotation marks unless they are > >>> absolutely necessary to convey a specific meaning (e.g., directly > >>> quoting another work). > >>> > >>> A few examples below from back-to-back sentences in which quotation > >>> seems to be used inconsistently when used with "Transport Class Route > >>> Target Extended community". There are many other uses of quotation > >>> marks with many other terms to review. > >>> > >>> Original: > >>> These mechanisms are applied to BGP CT routes (AFI/SAFI: 1/76 or 2/76) > >>> using "Transport Class Route Target Extended community". > >>> > >>> vs. > >>> > >>> A BGP speaker that implements procedures described in this document > >>> and Route Target Constrain [RFC4684] MUST also apply the RTC > >>> procedures to the Transport Class Route Target Extended communities > >>> carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76). > >>> > >>> > >>> and see the mixed use in this paragraph: > >>> > >>> This document also reserves the Non-Transitive version of Transport > >>> Class extended community (Section 13.2.1.1.2) for future use. The > >>> "Non-Transitive Transport Class" Route Target Extended Community is > >>> not used. If received, it is considered equivalent in functionality > >>> to the Transitive Transport Class Route Target Extended Community, > >>> except for the difference in Transitive bit flag. > >>> > >>> g) Other documents in this cluster do not use quotations around field > >>> names (and RFC-to-be 9830 chose to skip quotes for field names in > >>> AUTH48). > >>> > >>> As there is mixed use in this document, would you like to update to > >>> match this convention? Some examples: > >>> > >>> "Transport Class ID" field > >>> 'Transport Class ID' field > >>> Policy Color field > >>> Next hop Address field > >>> BGP next hop field > >>> Local Administrator field > >>> MPLS Label field > >>> <TC> field > >>> "Type" field > >>> Value field > >>> 'Color' field > >>> > >>> > >>> --> > >>> > >>> > >>> 24) <!--[rfced] Please review uses of the slash "/" character in text and > >>> consider whether "and", "or", or "and/or" might be clearer for > >>> the reader. --> > >>> > >>> > >>> 25) <!--[rfced] Please note that we have removed the linking of some terms > >>> in the document as links are provided in the citations > >>> immediately adjacent to the terms. Please let us know any > >>> objections. --> > >>> > >>> > >>> 26) <!-- [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!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZnTZNoS1$ > >>> > > >>> 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. > >>> > >>> Megan Ferguson > >>> RFC Production Center > >>> > >>> > >>> *****IMPORTANT***** > >>> > >>> Updated 2025/08/19 > >>> > >>> 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!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZstiK5j7$ > >>> ). > >>> > >>> 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!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZt6OaEvX$ > >>> ). > >>> > >>> * 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!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZi1qSbP_$ > >>> >. > >>> > >>> * 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!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZnfk71To$ > >>> > >>> * The archive itself: > >>> > >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZuVpXIoS$ > >>> > >>> * 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/rfc9832.xml__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZoweX5uA$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZjPUtWjU$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.pdf__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZj1i_6IV$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.txt__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZhDbPuaY$ > >>> > >>> Diff file of the text: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-diff.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlBYxDQS$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-rfcdiff.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZrY73q37$ > >>> (side by side) > >>> > >>> Diff of the XML: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-xmldiff1.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlTF61c9$ > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9832__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZu7y6odS$ > >>> > >>> Please let us know if you have any questions. > >>> > >>> Thank you for your cooperation, > >>> > >>> RFC Editor > >>> > >>> -------------------------------------- > >>> RFC9832 (draft-ietf-idr-bgp-ct-39) > >>> > >>> Title : BGP Classful Transport Planes > >>> Author(s) : K. Vairavakkalai, Ed., N. Venkataraman, Ed. > >>> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas > >>> > >>> 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
