Sabrina, Looks great - thanks!
Megan Ferguson RPC Production Center > On Sep 3, 2025, at 2:10 PM, Sabrina Tanamal via RT <iana-mat...@iana.org> > wrote: > > 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
