Authors, Now that we have all necessary approvals, the IANA updates have been confirmed, and the other documents in the cluster have completed AUTH48, we will move the three documents from Cluster C534 forward in the publication process at this time.
The relevant cluster information can be found here: https://www.rfc-editor.org/cluster_info.php?cid=C534 Thank you all for your time and attention during AUTH48. Megan Ferguson RPC Production Center > On Sep 4, 2025, at 7:32 AM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > 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
