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 here https://www.rfc-editor.org/cluster_info.php?cid=C534 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://www.rfc-editor.org/authors/rfc9832.txt >> https://www.rfc-editor.org/authors/rfc9832.pdf >> https://www.rfc-editor.org/authors/rfc9832.html >> https://www.rfc-editor.org/authors/rfc9832.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9832-diff.html (comprehensive) >> https://www.rfc-editor.org/authors/rfc9832-rfcdiff.html (side by side) >> >> https://www.rfc-editor.org/authors/rfc9832-auth48diff.html (AUTH48 changes >> only) >> https://www.rfc-editor.org/authors/rfc9832-auth48rfcdiff.html (side by side) >> >> The AUTH48 status page for this document can be found here: >> https://www.rfc-editor.org/auth48/rfc9832 >> >> The relevant cluster information can be found here: >> https://www.rfc-editor.org/cluster_info.php?cid=C534 >> >> >> 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://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/rfc9832.xml >>> >>> 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://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/369e32c114263e81a02fb556f80c765daa8b7927/rfc9832.xml >>> >>> 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://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/rfc9832.xml), >>> 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
