Hi Kaliraj, Megan, all, These updates are complete:
https://www.iana.org/assignments/safi-namespace https://www.iana.org/assignments/iana-routing-types If any other changes are required, just let us know. Thanks, Sabrina On Sat Aug 30 01:35:43 2025, kali...@juniper.net wrote: > Hi Sabrina, > > Yes the description in iana-routing-types YANG Module can be updated > to the following: > > enum classful-transport-safi { > value 76; > description > "Classful Transport (CT) SAFI"; > } > > Thanks > Kaliraj > > > > Juniper Business Use Only > From: Sabrina Tanamal via RT <iana-mat...@iana.org> > Date: Friday, August 29, 2025 at 3:02 PM > To: mfergu...@staff.rfc-editor.org <mfergu...@staff.rfc-editor.org> > Cc: sha...@ndzh.com <sha...@ndzh.com>, rfc-edi...@rfc-editor.org <rfc- > edi...@rfc-editor.org>, Natrajan Venkataraman <n...@juniper.net>, > Kaliraj Vairavakkalai <kali...@juniper.net>, John Scudder > <j...@juniper.net>, idr-cha...@ietf.org <idr-cha...@ietf.org>, idr- > a...@ietf.org <idr-...@ietf.org>, Reshma Das <dres...@juniper.net>, > draft-ietf-idr-bgp-ct.not...@ietf.org <draft-ietf-idr-bgp- > ct.not...@ietf.org>, auth48archive@rfc-editor.org <auth48archive@rfc- > editor.org> > Subject: [IANA #1428425] Re: [IANA] AUTH48: RFC-to-be 9832 <draft- > ietf-idr-bgp-ct-39> for your review > [External Email. Be cautious of content] > > > Hi Megan, Authors, all, > > We have a question regarding this update. In the associated iana- > routing-types module at > https://urldefense.com/v3/__https://www.iana.org/assignments/iana- > routing-types__;!!NEt6yMaO- > gk!EJPYuaKPJ3q8icV9EuUEx8ji8JPf2lB9rHWY3cDQx9nqX0d7WsHJchdS1sP_dNfvDMUjQ9805nsJakPq2Y_- > $<https://urldefense.com/v3/__https:/www.iana.org/assignments/iana- > routing-types__;!!NEt6yMaO- > gk!EJPYuaKPJ3q8icV9EuUEx8ji8JPf2lB9rHWY3cDQx9nqX0d7WsHJchdS1sP_dNfvDMUjQ9805nsJakPq2Y_- > $> , we have the following entry: > > enum classful-transport-safi { > value 76; > description > "Classful-Transport SAFI."; > } > > Should this entry be updated? If so, please let us know what the enum > and description fields should contain. > > Thanks, > Sabrina > > On Thu Aug 28 23:17:10 2025, mfergu...@staff.rfc-editor.org wrote: > > IANA, > > > > Please update the SAFI Values registry at > > https://urldefense.com/v3/__https://www.iana.org/assignments/safi- > > namespace/safi-namespace.xhtml__;!!NEt6yMaO- > > gk!EJPYuaKPJ3q8icV9EuUEx8ji8JPf2lB9rHWY3cDQx9nqX0d7WsHJchdS1sP_dNfvDMUjQ9805nsJalxxcX3z$<https://urldefense.com/v3/__https:/www.iana.org/assignments/safi- > > namespace/safi-namespace.xhtml__;!!NEt6yMaO- > > gk!EJPYuaKPJ3q8icV9EuUEx8ji8JPf2lB9rHWY3cDQx9nqX0d7WsHJchdS1sP_dNfvDMUjQ9805nsJalxxcX3z$> > > 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- > > > a...@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-editor@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- > > > >> <https://urldefense.com/v3/__https:/www.rfc-> > > > >> editor.org/authors/rfc9832.txt__;!!NEt6yMaO- > > > >> gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ- > > > >> v1Og1erqnp$ > > > >> https://urldefense.com/v3/__https://www.rfc- > > > >> <https://urldefense.com/v3/__https:/www.rfc-> > > > >> editor.org/authors/rfc9832.pdf__;!!NEt6yMaO- > > > >> gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ- > > > >> v1OsHPrJ91$ > > > >> https://urldefense.com/v3/__https://www.rfc- > > > >> <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- > > > >> <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- > > > >> <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- > > > >> <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- > > > >> <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- > > > >> <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- > > > >> <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- > > > >> <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-<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- > > > >>> a...@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-<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- > > > >>> a...@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- > > > >>> a...@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- > > > >>> <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- > > > >>> <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- > > > >>> <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- > > > >>> <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- > > > >>> <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- > > > >>> <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- > > > >>> <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- > > > >>> <https://urldefense.com/v3/__https:/www.rfc-> > > > >>> editor.org/authors/rfc9832.xml__;!!NEt6yMaO- > > > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn- > > > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZoweX5uA$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> <https://urldefense.com/v3/__https:/www.rfc-> > > > >>> editor.org/authors/rfc9832.html__;!!NEt6yMaO- > > > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn- > > > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZjPUtWjU$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> <https://urldefense.com/v3/__https:/www.rfc-> > > > >>> editor.org/authors/rfc9832.pdf__;!!NEt6yMaO- > > > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn- > > > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZj1i_6IV$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> <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- > > > >>> <https://urldefense.com/v3/__https:/www.rfc-> > > > >>> editor.org/authors/rfc9832-diff.html__;!!NEt6yMaO- > > > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn- > > > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlBYxDQS$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> <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- > > > >>> <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- > > > >>> <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
