Hi Megan, Authors, all,
We have a question regarding this update. In the associated iana-routing-types
module at https://www.iana.org/assignments/iana-routing-types, 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://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml
> 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-...@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-
> > >> editor.org/authors/rfc9832.txt__;!!NEt6yMaO-
> > >> gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-
> > >> v1Og1erqnp$
> > >> https://urldefense.com/v3/__https://www.rfc-
> > >> editor.org/authors/rfc9832.pdf__;!!NEt6yMaO-
> > >> gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-
> > >> v1OsHPrJ91$
> > >> 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-
> > >> 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-
> > >> editor.org/authors/rfc9832-diff.html__;!!NEt6yMaO-
> > >> gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-
> > >> v1OiD6pEI8$ (comprehensive)
> > >> 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-
> > >> editor.org/authors/rfc9832-auth48diff.html__;!!NEt6yMaO-
> > >> gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-
> > >> v1OlbhPs7C$ (AUTH48 changes only)
> > >> 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-
> > >> editor.org/auth48/rfc9832__;!!NEt6yMaO-
> > >> gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-
> > >> v1Oryt4ZjY$
> > >>
> > >> The relevant cluster information can be found here:
> > >> 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-
> > >>> 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-
> > >>> 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-
> > >>> editor.org/search__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZupPNXMg$ . -->
> > >>>
> > >>>
> > >>> 2) <!--[rfced] We see mention of the "TEAs Network Slices
> > >>> Framework" in
> > >>> the Abstract, may we update as follows to clarify the document
> > >>> you are mentioning?
> > >>>
> > >>> Original:
> > >>> These constructs can be used, for example, to realize the "IETF
> > >>> Network Slice" defined in TEAS Network Slices framework.
> > >>>
> > >>>
> > >>> Perhaps:
> > >>> These constructs can be used, for example, to realize the "IETF
> > >>> Network Slice" defined in the TEAS Network Slices framework (RFC
> > >>> 9543).
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 3) <!--[rfced] In the following text snippets, please review the
> > >>> format
> > >>> of attributes for the following:
> > >>>
> > >>> a) Should all of these names be in all caps (for example, code 25
> > >>> is
> > >>> in initial caps while code 8 is in all caps)?
> > >>>
> > >>> b) Should they all use "attribute type code", "BGP attribute
> > >>> code", or
> > >>> "attribute code" in their parentheticals? Or are these purposely
> > >>> different?
> > >>>
> > >>> Original:
> > >>> A BGP attribute that carries community. Examples of BGP CCAs are
> > >>> COMMUNITIES (attribute code 8), EXTENDED COMMUNITIES (attribute
> > >>> code
> > >>> 16), IPv6 Address Specific Extended Community (attribute code
> > >>> 25), and
> > >>> LARGE_COMMUNITY (attribute code 32).
> > >>>
> > >>> ...
> > >>>
> > >>> TEA: Tunnel Encapsulation Attribute (attribute type code 23)
> > >>>
> > >>> ...
> > >>>
> > >>> It is carried in BGP extended community attribute (BGP attribute
> > >>> code
> > >>> 16).
> > >>>
> > >>> ...
> > >>>
> > >>> ..., or IPv6-address specific RT (BGP attribute code 25).
> > >>>
> > >>> ...
> > >>>
> > >>> ...UDP tunneling information is carried using the Tunnel
> > >>> Encapsulation
> > >>> Attribute (code 23)...
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 4) <!--[rfced] Please review the use of "color field" in the
> > >>> following
> > >>> text and let us know if it should instead be "Color Value
> > >>> field"
> > >>> to match the use in RFC 9012. (Note that the quotations
> > >>> around
> > >>> field names depend on your response to that related question.)
> > >>>
> > >>> Original:
> > >>>
> > >>> ...with the Flags field set to 0 and the color field set to 100.
> > >>>
> > >>>
> > >>> Perhaps:
> > >>> ...with the "Flags" field set to 0 and the "Color Value" field
> > >>> set to 100.
> > >>> -->
> > >>>
> > >>>
> > >>> 5) <!--[rfced] Regarding figures, artwork, and SVG:
> > >>>
> > >>> a) Please review that all lines in <artwork> are 69 characters or
> > >>> less. If not, please consider how figures may be updated in
> > >>> order to
> > >>> fit this limitation (some warnings of outdenting from xml2rfc
> > >>> exist).
> > >>>
> > >>> b) FYI - the RPC does not edit SVG figures. If any changes are
> > >>> made
> > >>> to their ASCII equivalents, authors should incorporate these
> > >>> changes
> > >>> into the SVG and resubmit these changes to the RPC.
> > >>>
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 6) <!-- [rfced] We had a few questions related to the text below:
> > >>>
> > >>> a) We note that [RFC4360] doesn't appear to use the term "EXT-
> > >>> COMM".
> > >>> Please review the following citation for accuracy.
> > >>>
> > >>> b) Please also review this text for redundancy and let us know
> > >>> if/how
> > >>> this text may be rephrased (we have already removed the EXT-COMM
> > >>> link).
> > >>>
> > >>> Current:
> > >>> The "Transport Class" Route Target Extended Community is a
> > >>> transitive
> > >>> extended community [RFC4360] of extended type, which has the
> > >>> format as shown in Figure 2.
> > >>> -->
> > >>>
> > >>>
> > >>> 7) <!--[rfced] Should the names in the following paragraph (and
> > >>> anywhere
> > >>> they are mentioned throughout the document) be made more
> > >>> uniform
> > >>> (i.e., should Route Target be added to the first use of
> > >>> "extended
> > >>> community")? See a later question related to the quotation
> > >>> use
> > >>> as well.
> > >>>
> > >>> Original:
> > >>> This document also reserves the Non-Transitive version of
> > >>> Transport
> > >>> Class extended community (Section 13.2.1.1.2) for future use.
> > >>> The
> > >>> "Non-Transitive Transport Class" Route Target Extended Community
> > >>> is
> > >>> not used. If received, it is considered equivalent in
> > >>> functionality
> > >>> to the Transitive Transport Class Route Target Extended
> > >>> Community,
> > >>> except for the difference in Transitive bit flag.
> > >>>
> > >>> Perhaps:
> > >>> This document also reserves the Non-Transitive version of the
> > >>> Transport
> > >>> Class Route Target extended community (Section 13.2.1.1.2) for
> > >>> future use. The
> > >>> Non-Transitive Transport Class Route Target extended community is
> > >>> not used. If received, it is considered equivalent in
> > >>> functionality
> > >>> to the Transitive Transport Class Route Target extended
> > >>> community,
> > >>> except for the difference in the Transitive bit flag.
> > >>> -->
> > >>>
> > >>>
> > >>> 8) <!-- [rfced] We note that "color:0:100" isn't used in
> > >>> [RFC9012]. It's
> > >>> defined in this document (See Section 2.1. Definitions and
> > >>> Notations). Please review the citation in the following text
> > >>> for
> > >>> accuracy (or need of a possible rewording).
> > >>>
> > >>> Current:
> > >>>
> > >>> An example of mapping community is "color:0:100", described in
> > >>> [RFC9012], or the "transport-target:0:100" described in Section
> > >>> 4.3 in
> > >>> this document.
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 9) <!--[rfced] If our addition of "exist" does not capture your
> > >>> intent, please review the original text and suggest
> > >>> another rephrase.
> > >>>
> > >>> Original:
> > >>> If more than one distinct Mapping Communities on an overlay
> > >>> route map
> > >>> to distinct Resolution Schemes with dissimilar Intents at a
> > >>> receiving
> > >>> node, it is considered a configuration error.
> > >>>
> > >>> Perhaps:
> > >>> If more than one distinct Mapping Community on an overlay route
> > >>> map
> > >>> to distinct Resolution Schemes with dissimilar Intents at a
> > >>> receiving
> > >>> node exist, it is considered a configuration error.
> > >>> -->
> > >>>
> > >>>
> > >>> 10) <!--[rfced] Because "information" is a noncount noun, it
> > >>> would be
> > >>> unusual to say "multiple information". How may we update?
> > >>> Perhaps "Multiple Types of Encapsulation Information"?
> > >>>
> > >>>
> > >>> Original:
> > >>> 6.3. Carrying multiple Encapsulation Information
> > >>>
> > >>> and
> > >>>
> > >>> ...route allows carrying multiple encapsulation information.
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 11) <!-- [rfced] We note that Section 3 of [RFC8669] uses
> > >>> "Prefix-SID"
> > >>> rather than "Prefix SID". May we update to make these
> > >>> consistent?
> > >>>
> > >>> Current:
> > >>>
> > >>> The SID information for SR with respect to MPLS Data Plane is
> > >>> carried
> > >>> as specified in Prefix SID attribute defined as part of Section 3
> > >>> of
> > >>> [RFC8669].
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 12) <!--[rfced] Please review our updates to the text below and
> > >>> confirm
> > >>> that we have interpreted your list correctly (i.e., the BGP CT
> > >>> route is originated with RD:EP in the NLRI along with a
> > >>> Transport
> > >>> Class RT, and the endpoint being a protocol next hop). If
> > >>> this
> > >>> is not the intent, please provide another rephrase.
> > >>>
> > >>> Original:
> > >>> The egress node of the tunnel, i.e. the tunnel endpoint (EP),
> > >>> originates the BGP CT route with RD:EP in the NLRI, Transport
> > >>> Class RT
> > >>> and PNH as EP.
> > >>>
> > >>> Current:
> > >>>
> > >>> The egress node of the tunnel, i.e., the tunnel endpoint (EP),
> > >>> originates the BGP CT route with RD:EP in the NLRI, a Transport
> > >>> Class
> > >>> RT, and a PNH as the EP.
> > >>>
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 13) <!-- [rfced] Please confirm the following citation as
> > >>> [RFC9350]
> > >>> doesn't appear to use the term "ISIS Flex-Algo" (we note that
> > >>> it
> > >>> does contain the term "Flex-Algorithm").
> > >>>
> > >>> Current:
> > >>>
> > >>> AS2 is further divided into two regions. There are three tunnel
> > >>> domains in provider's space: AS1 uses ISIS Flex-Algo [RFC9350]
> > >>> intra-domain tunnels. AS2 uses RSVP-TE intra-domain tunnels.
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 14) <!--[rfced] Please review the use of a comma in the following
> > >>> situations:
> > >>>
> > >>> a) Between "1" and "128" in the following. We have seen 1/128 in
> > >>> the
> > >>> earlier parts of this document: are these different meanings?
> > >>> This
> > >>> occurs in more than one place.
> > >>>
> > >>> Original:
> > >>>
> > >>> Service nodes PE11, PE12 negotiate service families (AFI: 1 and
> > >>> SAFIs
> > >>> 1, 128) on the BGP session with RR16.
> > >>>
> > >>> b) Throughout Section 8.3 and elsewhere in the document, we
> > >>> replaced
> > >>> many commas with "and" as we believe this was the intended
> > >>> meaning.
> > >>> Please review and let us know any objections.
> > >>> -->
> > >>>
> > >>>
> > >>> 15) <!--[rfced] We note that this document uses TC ID to refer to
> > >>> a
> > >>> Transport Class Identifier in the Terminology section. Please
> > >>> review the use of TC (without ID) in the text below where it
> > >>> seems the expansion is "Transport Class identifier" and let us
> > >>> know if/how to update.
> > >>>
> > >>> Original:
> > >>> ...transport-target:0:<TC> and a RT carrying <eSN>:<TC>, where TC
> > >>> is
> > >>> the Transport Class identifier, and eSN is the IP address used by
> > >>> SN
> > >>> as BGP next hop in its service route advertisements.
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 16) <!--[rfced] We see the following similar sentences in back-
> > >>> to-back
> > >>> paragraphs. Please review and let us know if/how we can
> > >>> reduce
> > >>> redundancy.
> > >>>
> > >>> Original:
> > >>>
> > >>> This is possible using mechanism described in Appendix D, such
> > >>> that
> > >>> advertisement of PE loopback addresses as next-hop in BGP service
> > >>> routes is confined to the region they belong to. An anycast
> > >>> IP-address called "Context Protocol Nexthop Address" (CPNH)
> > >>> abstracts
> > >>> the SNs in a region from other regions in the network.
> > >>>
> > >>> Such that advertisement of PE loopback addresses as next-hop in
> > >>> BGP
> > >>> service routes is confined to the region they belong to. An
> > >>> anycast
> > >>> IP-address called "Context Protocol Nexthop Address" (CPNH)
> > >>> abstracts
> > >>> the SNs in a region from other regions in the network.
> > >>>
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 17) <!--[rfced] We had the following questions related to the
> > >>> IANA
> > >>> Considerations section:
> > >>>
> > >>>
> > >>> a) We would like to make sure we understand the structure of the
> > >>> IANA
> > >>> Considerations section. Currently, we see:
> > >>>
> > >>> 13.1 and 13.2 - seem to add values to existing registries with
> > >>> some
> > >>> duplication to later sections (see question c below)
> > >>>
> > >>> 13.2.1-13.2.1.1.2 - all under a heading of "Existing Registries"
> > >>>
> > >>> 13.2.2 - 13.2.2 All under a heading of "New Registries"
> > >>>
> > >>> 13.3 - Adds two code points to an existing registry
> > >>>
> > >>>
> > >>> Perhaps we could update to something structured along the lines
> > >>> of
> > >>> updates to existing registries and creation of new ones?
> > >>>
> > >>> 13. IANA Considerations
> > >>> 13.1. Existing Registries
> > >>> 13.1.1. New BGP SAFI
> > >>> 13.1.2. New Format for BGP Extended Community
> > >>> 13.1.3. Registries for the "Type" Field
> > >>> 13.1.3.1. Transitive Types
> > >>> 13.1.3.2. Non-Transitive Types
> > >>> 13.1.4. MPLS OAM Code Points
> > >>> 13.2. New Registries
> > >>> 13.2.1. Transitive Transport Class Extended Community Sub-Types
> > >>> Registry
> > >>> 13.2.2. Non-Transitive Transport Class Extended Community Sub-
> > >>> Types Registry
> > >>>
> > >>>
> > >>> With something like the following text in Section 13 itself to
> > >>> introduce the actions:
> > >>>
> > >>> This document registers values in existing registries and creates
> > >>> new
> > >>> registries as described in the following subsections.
> > >>>
> > >>> NOTE: Please review our question c) below before responding.
> > >>>
> > >>> Please let us know if this restructuring would be agreeable.
> > >>>
> > >>> b) Please note that we have updated the capitalization (to
> > >>> lowercase)
> > >>> of the values in Tables 4 and 6 to match the use in the
> > >>> corresponding
> > >>> IANA registries. Please review and let us know any objections.
> > >>>
> > >>> c) Section 13.2 made us expect that 0xa would be registered in
> > >>> both
> > >>> the "BGP Transitive Extended Community Types" registry and the
> > >>> "BGP
> > >>> Non-Transitive Extended Community Types" registry.
> > >>>
> > >>> However, we do not see a registration of 0xa in the "BGP
> > >>> Non-Transitive Extended Community Types" registry at
> > >>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-
> > >>> extended-communities/bgp-extended-communities.xhtml*non-
> > >>> transitive__;Iw!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZgtmHNek$ .
> > >>>
> > >>> We do see an entry for "0x4a" for "Non-Transitive Transport
> > >>> Class",
> > >>> that is mentioned in the current Section 13.2.1.1.2.
> > >>>
> > >>> Please review this section for accuracy and redundancy with
> > >>> Sections
> > >>> 13.2.1.1.1 and 13.2.1.1.2 and let us know if/how we may update
> > >>> (or if
> > >>> we are just missing something on our end?).
> > >>>
> > >>> d) Section 13.2 says:
> > >>>
> > >>> Taking reference of [RFC7153] , the following assignments have
> > >>> been
> > >>> made:
> > >>>
> > >>> As none of the new entries in the registries list RFC 7153 as a
> > >>> reference themselves, should this text instead read:
> > >>>
> > >>> The registries below each reference RFC 7153.
> > >>>
> > >>> Or is there another way to rephrase?
> > >>>
> > >>> e) FYI - Any updates made to text that appears in IANA registries
> > >>> will
> > >>> be communicated by the RPC to IANA upon the completion of AUTH48.
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 18) <!--[rfced] As Section 14.1 (Transport Class ID) is no longer
> > >>> in
> > >>> the IANA Considerations sections, we have made some updates
> > >>> to help the reader. Please review this section carefully
> > >>> and let us know any concerns. -->
> > >>>
> > >>>
> > >>> 19) <!--[rfced] We note that the reference to
> > >>> draft-kaliraj-bess-bgp-sig-private-mpls-labels-09 has been
> > >>> replaced by draft-kaliraj-bess-bgp-mpls-namespaces. Please
> > >>> review this reference entry / citation and let us know if/how
> > >>> updates should be made.-->
> > >>>
> > >>>
> > >>> 20) <!--[rfced] The citation tag [BGP-CT-UPDATE-PACKING-TEST] is
> > >>> a bit
> > >>> long. Might we update to something shorter?-->
> > >>>
> > >>>
> > >>> 21) <!--[rfced] Please note that we have slightly modified the
> > >>> format of
> > >>> the Contributors section to make it more similar to the use in
> > >>> past RFCs and the guidance of RFC 7322 ("RFC Style Guide").
> > >>> Please let us know any objections.-->
> > >>>
> > >>>
> > >>> 22) <!--[rfced] We had the following questions/comments related
> > >>> to
> > >>> abbreviation use throughout the document:
> > >>>
> > >>> a) Abbreviations that appeared without expansion have been
> > >>> expanded
> > >>> upon first use following guidance from RFC 7322 ("RFC Style
> > >>> Guide").
> > >>> Please review these expansions for accuracy.
> > >>>
> > >>> b) We made some updates to the list of abbreviations in the
> > >>> Terminology
> > >>> section to match their use in past RFCs. We also flipped the
> > >>> expansion of TC-BE for a better 1:1 match between the
> > >>> abbreviation and
> > >>> the expansion. Please review carefully and let us know any
> > >>> objections.
> > >>>
> > >>> c) We see BN expanded as "Border Node". Past use in RFCs points
> > >>> to
> > >>> "Boundary Node". Please review and let us know if any updates
> > >>> should
> > >>> be made.
> > >>>
> > >>> d) The term "Labeled ISIS" and the abbreviation "L-ISIS" don't
> > >>> appear
> > >>> in RFC 8867, and RFC 8867 does not appear in the References
> > >>> section of
> > >>> this document. Please review the citation to this RFC in the
> > >>> Terminology section and let us know if/how to update.
> > >>>
> > >>> e) [RFC4684] uses "Route Target (RT) Constrain" rather than
> > >>> "Route
> > >>> Target Constrain (RTC)". We do see "Route Target Constraint
> > >>> (RTC)" in
> > >>> RFC 9125 (when citing RFC 4684). Please let us know if we should
> > >>> adopt
> > >>> the same form here (i.e., Route Target Constraint (RTC)).
> > >>>
> > >>>
> > >>> f) TC is expanded as Traffic Class in the companion documents
> > >>> (RFCs-to-be 9830 and 9831). This document expands it as
> > >>> Transport
> > >>> Class. Please review and let us know if we should make this
> > >>> consistent (see also TC ID and TC-BE).
> > >>>
> > >>> g) To follow the guidance at
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/styleguide/part2/*exp_abbrev__;Iw!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZkxxo_JU$ , we will
> > >>> update to have the following abbreviations expanded on first use
> > >>> and
> > >>> then use the abbreviated form thereafter unless we hear
> > >>> objection:
> > >>>
> > >>> Transport Class (TC)
> > >>> Route Target (RT)
> > >>> Route Target Constrain (RTC) (see related query above)
> > >>> Community Carrying Attribute (CCA)
> > >>> BGP Classful Transport (BGP CT)
> > >>> Address Family Identifier (AFI)
> > >>> Route Distinguisher (RD)
> > >>> Endpoint (EP)
> > >>> Next Hop (NH)
> > >>> Transport Route Database (TRDB)
> > >>> Ingress Service Node (iSN)
> > >>> Egress Service Node (eSN)
> > >>> Autonomous System (AS)
> > >>> Per-Hop Behavior (PHB)
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 23) <!--[rfced] We had the following questions related to
> > >>> terminology used throughout the document:
> > >>>
> > >>> a) Please note that we updated to use the following forms with
> > >>> relation
> > >>> to capitalization, hyphenation, etc. to match use/guidance in
> > >>> other
> > >>> documents in this cluster (see
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/cluster_info.php?cid=C534__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlogh6yX$ ). Please
> > >>> review
> > >>> and let us know any objections:
> > >>>
> > >>> BGP UPDATE message
> > >>> Color Extended Community
> > >>> Route Target extended community
> > >>> data plane
> > >>>
> > >>> Please review the different treatment of "Extended Community"
> > >>> vs. "extended community" and confirm that this difference is
> > >>> intentional.
> > >>>
> > >>> b) Keeping point a) in mind, please review the names of the
> > >>> communities and extended communities throughout the document for
> > >>> consistency. We see varied use of quotation marks, places where
> > >>> words
> > >>> may be missing, differences in capitalization, etc. Examples
> > >>> below:
> > >>>
> > >>> Transport Class Route Target extended community vs. Transport
> > >>> Class
> > >>> extended community vs. "Transport Class" extended community (see
> > >>> also
> > >>> Transport Class Route Target vs. transport-class route-target)
> > >>>
> > >>> Transport Target Extended community
> > >>>
> > >>> transitive extended community vs. Transitive Extended Community
> > >>>
> > >>> Non-Transitive Extended Community vs. "Non-Transitive Transport
> > >>> Class"
> > >>> Route Target extended community vs. Non-Transitive Transport
> > >>> Class
> > >>> Extended community vs. "Non-Transitive Transport Class route
> > >>> target
> > >>> extended community" vs. Non-Transitive Transport Class vs.
> > >>> Non-Transitive version of the Transport Class extended community
> > >>>
> > >>> Mapping Community vs. Mapping community vs. mapping community
> > >>>
> > >>> Community vs. community (when used alone; see also communities)
> > >>>
> > >>> Extended Community vs. extended community (when used alone; see
> > >>> also
> > >>> extended communities)
> > >>>
> > >>>
> > >>> c) The following terminology seems to use inconsistent marking
> > >>> (i.e.,
> > >>> capitalization, hyphenation, etc.) throughout the document.
> > >>> Please
> > >>> review these instances and consider if/how they may be made
> > >>> uniform:
> > >>>
> > >>> Resolution Scheme vs. resolution scheme vs. "Resolution Scheme"
> > >>>
> > >>> Route Target vs. route target
> > >>>
> > >>> Ingress domain vs. ingress domain
> > >>>
> > >>> Ingress node vs. ingress node
> > >>>
> > >>> Ingress PE vs. ingress PE (see also egress)
> > >>>
> > >>> Intent vs. intent
> > >>>
> > >>> Inter-AS vs. inter-AS (and Intra-AS vs. intra-AS)
> > >>>
> > >>> Option C vs. option c (and others like option b etc.)
> > >>>
> > >>> BGP Classful Transport vs. Classful Transport
> > >>>
> > >>> Classful Transport BGP route vs. Classful Transport route vs. BGP
> > >>> Classful Transport family routes
> > >>>
> > >>> Classful Transport NLRI vs. Classful Transport NLRI Prefix
> > >>> vs. Classful Transport prefix vs. "Classful Transport" SAFI NLRI
> > >>>
> > >>> Transport Tunnels vs. transport tunnels
> > >>>
> > >>> Transport-target vs. transport-target
> > >>>
> > >>> transport-target:0:100 vs. transport route target 0:200 vs. route
> > >>> target "transport-target:0:100" vs. transport class 100 routes
> > >>>
> > >>> Transport Family vs. Transport family vs. transport family (see
> > >>> also
> > >>> families)
> > >>>
> > >>> Transport class vs. transport class vs. Transport Class
> > >>>
> > >>> "Transport Class ID" field vs. "Transport Class" identifier
> > >>>
> > >>> Transport Class ID 100 vs. Transport Class 100
> > >>>
> > >>> Color vs. color vs. 'Color' vs. "Color" (FYI 9830 is using Color)
> > >>>
> > >>> color:0:100500 vs. Color:0:100
> > >>>
> > >>> Transposition scheme vs. transposition scheme vs. Transposition
> > >>> Scheme
> > >>>
> > >>> operator vs. Operator
> > >>>
> > >>> service family vs. Service family
> > >>>
> > >>> service route vs. Service route
> > >>>
> > >>> FLEX-ALGO vs. Flex-Algo vs. FlexAlgo
> > >>>
> > >>> MPLS label vs. MPLS Label
> > >>>
> > >>> Implicit-NULL vs. Implicit Null vs. Implicit NULL
> > >>>
> > >>> special label 3 (Implicit NULL) vs. value 3 (Implicit-NULL)
> > >>>
> > >>> RD:EP vs. "RD:EP" vs. 'RD:Endpoint' vs. "RD:Endpoint" vs. RD,EP
> > >>> vs. "RD, EP" (see also RD, RT)
> > >>>
> > >>> gold vs. Gold
> > >>>
> > >>> bronze vs. Bronze
> > >>>
> > >>> d) Terms including "best effort": we have updated these terms to
> > >>> appear as hyphenated when in attributive position (modifying a
> > >>> noun)
> > >>> but left them open otherwise. However, there is variance related
> > >>> to
> > >>> their quotation, capitalization, etc. remaining. Please review
> > >>> the
> > >>> terms and let us know if/how further updates for uniformity may
> > >>> be
> > >>> made (note: the list below includes our hyphenation changes).
> > >>>
> > >>> best-effort transport class vs. Best-Effort Transport Class
> > >>>
> > >>> "Best-Effort" transport class TRDB vs. Best-Effort TRDB vs. TRDB
> > >>> for best effort
> > >>>
> > >>> "best-effort" transport class routes vs. best-effort transport
> > >>> route
> > >>>
> > >>> 'Best-effort' SLA vs. best-effort SLA
> > >>>
> > >>> "Best-Effort Transport Class Route Target" vs. Best-Effort
> > >>> Transport Class Route Target
> > >>>
> > >>> "Best-Effort" Resolution Scheme vs. Best-effort resolution scheme
> > >>> vs. best-effort resolution scheme
> > >>>
> > >>>
> > >>>
> > >>> e) Please review the following similar instances and let us know
> > >>> if/how they should be made uniform.
> > >>>
> > >>> SAFI 76 (BGP CT)
> > >>> SAFI 76 "Classful Transport"
> > >>> AFI/SAFI 1/76 (Classful Transport SAFI)
> > >>>
> > >>> AFI/SAFI 1/128 (MPLS-labeled VPN address)
> > >>> Inet-VPN SAFI 128
> > >>> SAFI 128 (L3VPN)
> > >>>
> > >>> f) There are many places in which quotation marks are used that
> > >>> we are
> > >>> uncertain of their meaning/purpose and they are inconsistent
> > >>> (appearing sometimes and not others or single quotes in some
> > >>> places
> > >>> while double or no quotes in others).
> > >>>
> > >>> Please review the use of quotation marks generally throughout the
> > >>> document. We suggest removing quotation marks unless they are
> > >>> absolutely necessary to convey a specific meaning (e.g., directly
> > >>> quoting another work).
> > >>>
> > >>> A few examples below from back-to-back sentences in which
> > >>> quotation
> > >>> seems to be used inconsistently when used with "Transport Class
> > >>> Route
> > >>> Target Extended community". There are many other uses of
> > >>> quotation
> > >>> marks with many other terms to review.
> > >>>
> > >>> Original:
> > >>> These mechanisms are applied to BGP CT routes (AFI/SAFI: 1/76 or
> > >>> 2/76)
> > >>> using "Transport Class Route Target Extended community".
> > >>>
> > >>> vs.
> > >>>
> > >>> A BGP speaker that implements procedures described in this
> > >>> document
> > >>> and Route Target Constrain [RFC4684] MUST also apply the RTC
> > >>> procedures to the Transport Class Route Target Extended
> > >>> communities
> > >>> carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76).
> > >>>
> > >>>
> > >>> and see the mixed use in this paragraph:
> > >>>
> > >>> This document also reserves the Non-Transitive version of
> > >>> Transport
> > >>> Class extended community (Section 13.2.1.1.2) for future use.
> > >>> The
> > >>> "Non-Transitive Transport Class" Route Target Extended Community
> > >>> is
> > >>> not used. If received, it is considered equivalent in
> > >>> functionality
> > >>> to the Transitive Transport Class Route Target Extended
> > >>> Community,
> > >>> except for the difference in Transitive bit flag.
> > >>>
> > >>> g) Other documents in this cluster do not use quotations around
> > >>> field
> > >>> names (and RFC-to-be 9830 chose to skip quotes for field names in
> > >>> AUTH48).
> > >>>
> > >>> As there is mixed use in this document, would you like to update
> > >>> to
> > >>> match this convention? Some examples:
> > >>>
> > >>> "Transport Class ID" field
> > >>> 'Transport Class ID' field
> > >>> Policy Color field
> > >>> Next hop Address field
> > >>> BGP next hop field
> > >>> Local Administrator field
> > >>> MPLS Label field
> > >>> <TC> field
> > >>> "Type" field
> > >>> Value field
> > >>> 'Color' field
> > >>>
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> 24) <!--[rfced] Please review uses of the slash "/" character in
> > >>> text and
> > >>> consider whether "and", "or", or "and/or" might be clearer for
> > >>> the reader. -->
> > >>>
> > >>>
> > >>> 25) <!--[rfced] Please note that we have removed the linking of
> > >>> some terms
> > >>> in the document as links are provided in the citations
> > >>> immediately adjacent to the terms. Please let us know any
> > >>> objections. -->
> > >>>
> > >>>
> > >>> 26) <!-- [rfced] Please review the "Inclusive Language" portion
> > >>> of the
> > >>> online Style Guide
> > >>> <https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZnTZNoS1$ >
> > >>> and let us know if any changes are needed. Updates of this
> > >>> nature typically result in more precise language, which is
> > >>> helpful for readers.
> > >>>
> > >>>
> > >>>
> > >>> Note that our script did not flag any words in particular, but
> > >>> this
> > >>> should still be reviewed as a best practice.
> > >>>
> > >>> -->
> > >>>
> > >>>
> > >>> Thank you.
> > >>>
> > >>> Megan Ferguson
> > >>> RFC Production Center
> > >>>
> > >>>
> > >>> *****IMPORTANT*****
> > >>>
> > >>> Updated 2025/08/19
> > >>>
> > >>> RFC Author(s):
> > >>> --------------
> > >>>
> > >>> Instructions for Completing AUTH48
> > >>>
> > >>> Your document has now entered AUTH48. Once it has been reviewed
> > >>> and
> > >>> approved by you and all coauthors, it will be published as an
> > >>> RFC.
> > >>> If an author is no longer available, there are several remedies
> > >>> available as listed in the FAQ
> > >>> (https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/faq/__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZstiK5j7$ ).
> > >>>
> > >>> You and you coauthors are responsible for engaging other parties
> > >>> (e.g., Contributors or Working Group) as necessary before
> > >>> providing
> > >>> your approval.
> > >>>
> > >>> Planning your review
> > >>> ---------------------
> > >>>
> > >>> Please review the following aspects of your document:
> > >>>
> > >>> * RFC Editor questions
> > >>>
> > >>> Please review and resolve any questions raised by the RFC Editor
> > >>> that have been included in the XML file as comments marked as
> > >>> follows:
> > >>>
> > >>> <!-- [rfced] ... -->
> > >>>
> > >>> These questions will also be sent in a subsequent email.
> > >>>
> > >>> * Changes submitted by coauthors
> > >>>
> > >>> Please ensure that you review any changes submitted by your
> > >>> coauthors. We assume that if you do not speak up that you
> > >>> agree to changes submitted by your coauthors.
> > >>>
> > >>> * Content
> > >>>
> > >>> Please review the full content of the document, as this cannot
> > >>> change once the RFC is published. Please pay particular
> > >>> attention to:
> > >>> - IANA considerations updates (if applicable)
> > >>> - contact information
> > >>> - references
> > >>>
> > >>> * Copyright notices and legends
> > >>>
> > >>> Please review the copyright notice and legends as defined in
> > >>> RFC 5378 and the Trust Legal Provisions
> > >>> (TLP –
> > >>> https://urldefense.com/v3/__https://trustee.ietf.org/license-
> > >>> info__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZt6OaEvX$ ).
> > >>>
> > >>> * Semantic markup
> > >>>
> > >>> Please review the markup in the XML file to ensure that elements
> > >>> of
> > >>> content are correctly tagged. For example, ensure that
> > >>> <sourcecode>
> > >>> and <artwork> are set correctly. See details at
> > >>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-
> > >>> vocabulary__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZi1qSbP_$ >.
> > >>>
> > >>> * Formatted output
> > >>>
> > >>> Please review the PDF, HTML, and TXT files to ensure that the
> > >>> formatted output, as generated from the markup in the XML file,
> > >>> is
> > >>> reasonable. Please note that the TXT will have formatting
> > >>> limitations compared to the PDF and HTML.
> > >>>
> > >>>
> > >>> Submitting changes
> > >>> ------------------
> > >>>
> > >>> To submit changes, please reply to this email using ‘REPLY ALL’
> > >>> as all
> > >>> the parties CCed on this message need to see your changes. The
> > >>> parties
> > >>> include:
> > >>>
> > >>> * your coauthors
> > >>>
> > >>> * rfc-edi...@rfc-editor.org (the RPC team)
> > >>>
> > >>> * other document participants, depending on the stream (e.g.,
> > >>> IETF Stream participants are your working group chairs, the
> > >>> responsible ADs, and the document shepherd).
> > >>>
> > >>> * auth48archive@rfc-editor.org, which is a new archival mailing
> > >>> list
> > >>> to preserve AUTH48 conversations; it is not an active
> > >>> discussion
> > >>> list:
> > >>>
> > >>> * More info:
> > >>>
> > >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-
> > >>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZnfk71To$
> > >>>
> > >>> * The archive itself:
> > >>>
> > >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZuVpXIoS$
> > >>>
> > >>> * Note: If only absolutely necessary, you may temporarily opt
> > >>> out
> > >>> of the archiving of messages (e.g., to discuss a sensitive
> > >>> matter).
> > >>> If needed, please add a note at the top of the message that
> > >>> you
> > >>> have dropped the address. When the discussion is concluded,
> > >>> auth48archive@rfc-editor.org will be re-added to the CC list
> > >>> and
> > >>> its addition will be noted at the top of the message.
> > >>>
> > >>> You may submit your changes in one of two ways:
> > >>>
> > >>> An update to the provided XML file
> > >>> — OR —
> > >>> An explicit list of changes in this format
> > >>>
> > >>> Section # (or indicate Global)
> > >>>
> > >>> OLD:
> > >>> old text
> > >>>
> > >>> NEW:
> > >>> new text
> > >>>
> > >>> You do not need to reply with both an updated XML file and an
> > >>> explicit
> > >>> list of changes, as either form is sufficient.
> > >>>
> > >>> We will ask a stream manager to review and approve any changes
> > >>> that seem
> > >>> beyond editorial in nature, e.g., addition of new text, deletion
> > >>> of text,
> > >>> and technical changes. Information about stream managers can be
> > >>> found in
> > >>> the FAQ. Editorial changes do not require approval from a stream
> > >>> manager.
> > >>>
> > >>>
> > >>> Approving for publication
> > >>> --------------------------
> > >>>
> > >>> To approve your RFC for publication, please reply to this email
> > >>> stating
> > >>> that you approve this RFC for publication. Please use ‘REPLY
> > >>> ALL’,
> > >>> as all the parties CCed on this message need to see your
> > >>> approval.
> > >>>
> > >>>
> > >>> Files
> > >>> -----
> > >>>
> > >>> The files are available here:
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/authors/rfc9832.xml__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZoweX5uA$
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/authors/rfc9832.html__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZjPUtWjU$
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/authors/rfc9832.pdf__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZj1i_6IV$
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/authors/rfc9832.txt__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZhDbPuaY$
> > >>>
> > >>> Diff file of the text:
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/authors/rfc9832-diff.html__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlBYxDQS$
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/authors/rfc9832-rfcdiff.html__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZrY73q37$ (side by
> > >>> side)
> > >>>
> > >>> Diff of the XML:
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/authors/rfc9832-xmldiff1.html__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlTF61c9$
> > >>>
> > >>>
> > >>> Tracking progress
> > >>> -----------------
> > >>>
> > >>> The details of the AUTH48 status of your document are here:
> > >>> https://urldefense.com/v3/__https://www.rfc-
> > >>> editor.org/auth48/rfc9832__;!!NEt6yMaO-
> > >>> gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-
> > >>> CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZu7y6odS$
> > >>>
> > >>> Please let us know if you have any questions.
> > >>>
> > >>> Thank you for your cooperation,
> > >>>
> > >>> RFC Editor
> > >>>
> > >>> --------------------------------------
> > >>> RFC9832 (draft-ietf-idr-bgp-ct-39)
> > >>>
> > >>> Title : BGP Classful Transport Planes
> > >>> Author(s) : K. Vairavakkalai, Ed., N. Venkataraman, Ed.
> > >>> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas
> > >>>
> > >>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de
> > >>> Velde
> > >>>
> > >>
> > >
> >
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
