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
