Re: [auth48] AUTH48: RFC-to-be 9552 <draft-ietf-idr-rfc7752bis-17> for your review

[Alanna Paloma <[e-mail]>]

Hi Ketan,

As IANA actions are now done, we consider AUTH48 complete:
https://www.rfc-editor.org/auth48/rfc9552

Thank you for your attention and guidance during the AUTH48 process.
We will move this document forward in the publication process at this time.

Best regards,
RFC Editor/ap

> On Dec 19, 2023, at 12:21 PM, David Dong via RT <[e-mail]> wrote:
> 
> Hi Alanna,
> 
> These changes are complete; please see:
> 
> https://www.iana.org/assignments/bgp-ls-parameters/
> 
> Best regards,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> On Tue Dec 19 17:49:55 2023, [e-mail] wrote:
>> IANA,
>> 
>> Please make the following updates to the “BGP-LS NLRI and Attribute
>> TLVs” registry <https://www.iana.org/assignments/bgp-ls-
>> parameters/bgp-ls-parameters.xhtml#node-descriptor-link-descriptor-
>> prefix-descriptor-attribute-tlv> to match the edited document at
>> https://www.rfc-editor.org/authors/rfc9552-diff.html
>> 
>> 1) Expand “ID” to be “Identifier” in the Description column of code
>> point 263.
>> 2) Update the section citation from Section 5.2.3 to Section 5.2.3.1
>> for code point 264.
>> 3) Update the section citation from Section 5.2.3 to Section 5.2.3.2
>> for code point 265.
>> 4) Add “(deprecated)” to the Description column of code point 513.
>> 
>> Old:
>> TLV Code Point  Description
>> Reference
>> 263                             Multi-Topology ID
>> [RFC-ietf-idr-rfc7752bis-16, Section 5.2.2.1]
>> 264                             OSPF Route Type
>> [RFC-ietf-idr-rfc7752bis-16, Section 5.2.3]
>> 265                             IP Reachability Information
>> [RFC-ietf-idr-rfc7752bis-16, Section 5.2.3]
>> 513                             BGP-LS Identifier
>> [RFC-ietf-idr-rfc7752bis-16, Section 5.2.1.4]
>> 
>> New:
>> TLV Code Point  Description
>> Reference
>> 263                             Multi-Topology Identifier
>> [RFC-ietf-idr-rfc7752bis-16, Section 5.2.2.1]
>> 264                             OSPF Route Type
>> [RFC-ietf-idr-rfc7752bis-16, Section 5.2.3.1]
>> 265                             IP Reachability Information
>> [RFC-ietf-idr-rfc7752bis-16, Section 5.2.3.2]
>> 513                             BGP-LS Identifier (deprecated)  [RFC-
>> ietf-idr-rfc7752bis-16, Section 5.2.1.4]
>> 
>> Thank you,
>> RFC Editor/ap
>> 
>>> On Dec 18, 2023, at 10:20 PM, Ketan Talaulikar
>>> <[e-mail]> wrote:
>>> 
>>> Hi Alanna,
>>> 
>>> Thanks for the updates and please consider this email as my approval
>>> for publication.
>>> 
>>> Thanks,
>>> Ketan
>>> 
>>> 
>>> On Tue, Dec 19, 2023 at 1:02 AM Alanna Paloma <[e-mail]>
>>> wrote:
>>> Hi Ketan,
>>> 
>>> Thank you for your reply.  We have updated as requested.
>>> 
>>> The files have been posted here (please refresh):
>>> https://www.rfc-editor.org/authors/rfc9552.xml
>>> https://www.rfc-editor.org/authors/rfc9552.txt
>>> https://www.rfc-editor.org/authors/rfc9552.html
>>> https://www.rfc-editor.org/authors/rfc9552.pdf
>>> 
>>> The relevant diff files have been posted here:
>>> https://www.rfc-editor.org/authors/rfc9552-diff.html (comprehensive
>>> diff)
>>> https://www.rfc-editor.org/authors/rfc9552-auth48diff.html (AUTH48
>>> changes)
>>> 
>>> Please review the document carefully and contact us with any further
>>> updates you may have.  Note that we do not make changes once a
>>> document is published as an RFC.
>>> 
>>> We will await approvals from each party listed on the AUTH48 status
>>> page below prior to moving this document forward in the publication
>>> process.
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9552
>>> 
>>> Thank you,
>>> RFC Editor/ap
>>> 
>>>> On Dec 18, 2023, at 5:40 AM, Ketan Talaulikar
>>>> <[e-mail]> wrote:
>>>> 
>>>> Also, some additional comments/questions on the diff itself.
>>>> 
>>>> 1) Sec 2.1 replaces "the IGP" with "IGP" - "the IGP" refers to
>>>> either OSPF or ISIS. Just wondering if "the" is not really needed
>>>> here? There are a few other similar usages in the rest of the
>>>> document as well (5.2.2, 5.3.1.4, 5.3.2.1, 5.6).
>>>> 
>>>> 2) Sec 4 there is a change from "max-aged" to "at the max age" -
>>>> this change is inappropriate. We can perhaps replace "max-aged"
>>>> with "aged out".
>>>> 
>>>> Thanks,
>>>> Ketan
>>>> 
>>>> 
>>>> On Mon, Dec 18, 2023 at 6:50 PM Ketan Talaulikar
>>>> <[e-mail]> wrote:
>>>> Hello,
>>>> 
>>>> Thanks for your help with this document. Please check inline below
>>>> for responses.
>>>> 
>>>> 
>>>> On Sat, Dec 16, 2023 at 7:45 AM <[e-mail]> wrote:
>>>> Ketan,
>>>> 
>>>> While reviewing this document during AUTH48, please resolve (as
>>>> necessary)
>>>> the following questions, which are also in the XML file.
>>>> 
>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that
>>>> appear in
>>>> the title) for use on https://www.rfc-editor.org/search. -->
>>>> 
>>>> 
>>>> 2) <!--[rfced] In the sentence below, does "that requires CPU-
>>>> intensive
>>>> or coordinated computations" refer to "Path Computation Element
>>>> (CPE)"?
>>>> 
>>>> Original:
>>>>   The IETF has defined the Path Computation Element (PCE)
>>>> [RFC4655] as
>>>>   a mechanism for achieving the computation of end-to-end TE paths
>>>> that
>>>>   cross the visibility of more than one TED or that requires CPU-
>>>>   intensive or coordinated computations.
>>>> 
>>>> Perhaps:
>>>>   The IETF has defined the Path Computation Element (PCE)
>>>> [RFC4655] as
>>>>   a mechanism for achieving the computation of end-to-end TE paths
>>>> that
>>>>   cross the visibility of more than one TED. The PCE also requires
>>>> CPU-
>>>>   intensive or coordinated computations.
>>>> -->
>>>> 
>>>> KT> The original text is more appropriate. The "cross the
>>>> KT> visibility of more than one TED"  and "requires CPU-intensive
>>>> KT> or coordinated computations" are the two OR clauses referring
>>>> KT> to "the computation of end-to-end TE paths".
>>>> 
>>>> 
>>>> 
>>>> 3) <!--[rfced] We do not see any mentions of "loose-hop-expansion"
>>>> in
>>>> RFC 3209. We note that the document includes instances of "loose
>>>> hop",
>>>> but there are no occurrences of "expansion". Please review and let
>>>> us
>>>> know if the citation requires any updates.
>>>> 
>>>> Original:
>>>>   Per-domain path
>>>>   computation uses a technique called "loose-hop-expansion"
>>>> [RFC3209]
>>>>   and selects the exit ABR and other ABRs or AS Border Routers
>>>> (ASBRs)
>>>>   using the IGP-computed shortest path topology for the remainder
>>>> of
>>>>   the path.
>>>>   -->
>>>> 
>>>> KT> How about the following:
>>>> Per-domain path
>>>> computation selects the exit ABR and other ABRs or AS Border
>>>> Routers (ASBRs)
>>>> as loose-hops [RFC3209] and using the IGP-computed shortest path
>>>> topology for the
>>>> remainder of the path.
>>>> 
>>>> 
>>>> 
>>>> 4) <!--[rfced] May we update the commas in this list as follows?
>>>> 
>>>> Original:
>>>>   (2) a BGP
>>>>   path attribute (BGP-LS Attribute) that carries properties of the
>>>>   link, node, or prefix objects such as the link and prefix metric
>>>> or
>>>>   auxiliary Router-IDs of nodes, etc.
>>>> 
>>>> Perhaps:
>>>>   (2) a BGP
>>>>   path attribute (BGP-LS Attribute) that carries properties of the
>>>>   link, node, or prefix objects such as the link and prefix
>>>> metric,
>>>>   auxiliary Router-IDs of nodes, etc.
>>>>   -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 5) <!-- [rfced] Tables 3 and 18 have entries for the following:
>>>> 
>>>> 513         | BGP-LS Identifier (deprecated)
>>>> 
>>>> Should the entry be marked as deprecated in the IANA registry
>>>> <https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-
>>>> parameters.xhtml#node-descriptor-link-descriptor-prefix-descriptor-
>>>> attribute-tlv>?
>>>> -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 6) <!--[rfced] The sentences below read awkwardly with "direct or
>>>> static".
>>>> Please review and let us know if/how they may be updated.
>>>> 
>>>> Original:
>>>>   This is a mandatory TLV when
>>>>   originating information from IS-IS, OSPF, direct or static.
>>>>   ...
>>>>   When the node is running an IGP protocol,
>>>>   an implementation MAY choose to use the IGP Router-ID for direct
>>>>   or static.
>>>> 
>>>> Perhaps:
>>>>   This is a mandatory TLV when
>>>>   originating information from IS-IS, OSPF, 'Direct', or 'Static
>>>>   configuration'.
>>>>   ...
>>>>   When the node is running an IGP protocol,
>>>>   an implementation MAY choose to use the IGP Router-ID for
>>>> 'Direct'
>>>>   or 'Static configuration'.
>>>> -->
>>>> 
>>>> KT> Looks better indeed.
>>>> 
>>>> 
>>>> 
>>>> 7) <!-- [rfced] There is a slight difference between the sections
>>>> referenced in Tables 5 and 18.  The reference in the IANA registry
>>>> matches
>>>> what appears in Table 18.  Should the section references be updated
>>>> for
>>>> consistency?  Perhaps they should match what appears Table 5?
>>>> 
>>>> Table 5 (Section 5.2.3):
>>>>  |      264       | OSPF Route Type           |    1     | Section
>>>> |
>>>>  |                |                           |          | 5.2.3.1
>>>> |
>>>>  |      265       | IP Reachability           | variable | Section
>>>> |
>>>>  |                | Information               |          | 5.2.3.2
>>>> |
>>>> 
>>>> 
>>>> Table 18 (Section 9):
>>>>    |      264       | OSPF Route Type         | Section 5.2.3
>>>> |
>>>>    |      265       | IP Reachability         | Section 5.2.3
>>>> |
>>>>    |                | Information             |
>>>> |
>>>> -->
>>>> 
>>>> KT> Good catch. Table 5 is indeed correct and the others have wrong
>>>> KT> section references for these TLVs.
>>>> 
>>>> 
>>>> 
>>>> 8) <!--[rfced] We note that Figure 13 includes a field called
>>>> "Route
>>>> Type". Should "OSPF" be removed from this text that precedes Figure
>>>> 13?
>>>> 
>>>> Original:
>>>>   The OSPF Route Type field follows the route types defined in the
>>>> OSPF
>>>>   protocol and can be one of the following:
>>>> 
>>>> Perhaps:
>>>>   The Route Type field follows the route types defined in the OSPF
>>>>   protocol and can be one of the following:
>>>>   -->
>>>> 
>>>> KT> We could not fit "OSPF Route Type" in that figure with the 8-
>>>> KT> bit width and hence it was abbreviated to "Route Type". We can
>>>> KT> use "Route Type" in the text as well to be consistent.
>>>> 
>>>> 
>>>> 
>>>> 9) <!-- [rfced] The following appears in Table 7:
>>>> 
>>>> | 'T' | Attached Bit | [ISO10589] |
>>>> 
>>>> The following appears in Table 14:
>>>> 
>>>> |  1  | Attached Bit (A-bit) |  RFC 9552 |
>>>> 
>>>> Should Table 7 be updated to reflect 'A' in the Bit column?
>>>> -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 10) <!--[rfced] To parallel the fields of other figures, should
>>>> "Opaque
>>>> node attributes" and "Opaque link attributes" be capitalized in
>>>> Figures 18 and 23, respectively?
>>>> 
>>>> Original:
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>>>> +-+
>>>>     //               Opaque node attributes (variable)
>>>> //
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>>>> +-+
>>>> 
>>>> Figure 18: Opaque Node Attribute Format
>>>> 
>>>> 
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> //                Opaque link attributes (variable)            //
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> 
>>>> Figure 23: Opaque Link Attribute TLV Format
>>>> -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 11) <!--[rfced] Should the parentheses around "SRLG" proceeding
>>>> "IPv4"
>>>> be removed to parallel "SRLG" proceeding "IPv6"?
>>>> 
>>>> Original:
>>>>   In IS-IS, the SRLG
>>>>   information is carried in two different TLVs: the IPv4 (SRLG)
>>>> TLV
>>>>   (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139)
>>>>   defined in [RFC6119].
>>>> 
>>>> Perhaps:
>>>>   In IS-IS, the SRLG
>>>>   information is carried in two different TLVs: the IPv4 SRLG TLV
>>>>   (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139)
>>>>   defined in [RFC6119].
>>>>   -->
>>>> 
>>>> KT> Actually these are the GMPLS-SRLG TLV (for IPv4) (Type 138)
>>>> KT> defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) defined
>>>> KT> in [RFC6119].
>>>> 
>>>> 
>>>> 
>>>> 12) <!--[rfced] We note that the "local address" bit listed in RFC
>>>> 5340
>>>> lists the bit value as "LA-bit". Should "L" (Table 11) be updated
>>>> to "LA-bit"?
>>>> -->
>>>> 
>>>> KT> Not needed. We can keep as is since they are separate protocols
>>>> KT> (BGP-LS and OSPF) and this is a bis RFC.
>>>> 
>>>> 
>>>> 
>>>> 13) <!--[rfced] May we update instances of "Extened IGP Route Tag"
>>>> to be
>>>> "IGP Extened Route Tag" to reflect the defined code point in IANA's
>>>> "BGP-LS NLRI and Attribute TLVs" registry? If yes, these updates
>>>> will
>>>> be made in Section 5.3.3.3.
>>>>   -->
>>>> 
>>>> KT> Yes.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 14) <!--[rfced] May we update the sentence below to improve
>>>> readability?
>>>> 
>>>> Original:
>>>>   An originating router shall use this TLV for encoding
>>>> information
>>>>   specific to the protocol advertised in the NLRI header Protocol-
>>>> ID
>>>>   field or new protocol extensions to the protocol as advertised
>>>> in the
>>>>   NLRI header Protocol-ID field for which there is no protocol-
>>>> neutral
>>>>   representation in the BGP Link-State NLRI.
>>>> 
>>>> Perhaps:
>>>>   An originating router shall use this TLV for encoding
>>>> information
>>>>   specific to the protocol advertised in the NLRI header Protocol-
>>>> ID
>>>>   field or it shall use new protocol extensions for the protocol
>>>> as
>>>>   advertised in the NLRI header Protocol-ID field for which there
>>>> is no
>>>>   protocol-neutral representation in the BGP Link-State NLRI.
>>>>   -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 15) <!--[rfced] FYI, we've updated "E-AS-External-Prefix-LSA" to
>>>> "E-AS-External-LSA" to match what appears in Section 4.5 of RFC
>>>> 8362.
>>>> Please let us know of any concerns.
>>>> 
>>>> Original:
>>>>   In the case of OSPFv3, this
>>>>   TLV MUST NOT be used to advertise TLVs other than those in the
>>>> OSPFv3
>>>>   E-Inter-Area-Prefix-LSA, E-Intra-Area-Prefix-LSA, E-AS-External-
>>>>   Prefix-LSA, and E-NSSA-LSA [RFC8362].
>>>> 
>>>> Current:
>>>>   In the case of OSPFv3, this
>>>>   TLV MUST NOT be used to advertise TLVs other than those in the
>>>> OSPFv3
>>>>   E-Inter-Area-Prefix-LSA, E-Intra-Area-Prefix-LSA, E-AS-External-
>>>> LSA,
>>>>   and E-NSSA-LSA [RFC8362].
>>>> -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 16) <!--[rfced] May we update this sentence as follows for clarity?
>>>> 
>>>> Original:
>>>>   Consider a point-to-point link between two routers, A and B,
>>>> that
>>>>   initially were OSPFv2-only routers and then IS-IS is enabled on
>>>> them.
>>>> 
>>>> Perhaps:
>>>>   Consider a point-to-point link between two routers, A and B,
>>>> which
>>>>   initially were OSPFv2-only routers and then had IS-IS enabled on
>>>> them.
>>>>   -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 17) <!-- [rfced] Terminology
>>>> 
>>>> a) Throughout the text, the following terminology appears to be
>>>> used
>>>> inconsistently. Please review these occurrences and let us know
>>>> if/how they
>>>>  may be made consistent.
>>>> 
>>>> Broadcast LAN / broadcast LAN
>>>> Multi-Topology ID / Multi-Topology Identifier
>>>> Node Name / node name
>>>> Route Reflector / route reflector
>>>> 
>>>> KT> The 2nd one (on the right) for all of the above
>>>> 
>>>> 
>>>> b) To parallel RFC 7752, may we update the following terms to the
>>>> ones
>>>> listed on the left.
>>>> 
>>>> link-local IPv6 address / IPv6 link-local address
>>>> path attribute length / Path Attribute Length
>>>> 
>>>> KT> The 2nd ones (on the right) are more appropriate
>>>> 
>>>> 
>>>> c) FYI, we made the following terms capitalized for consistency to
>>>> parallel
>>>> other BGP terminology. Please review and let us know if further
>>>> updates
>>>> are necessary.
>>>> 
>>>> BGP Attribute
>>>> BGP Decision Process
>>>> BGP Next-Hop
>>>> -> does this always refer to the attribute?
>>>> 
>>>> KT> Only in sec 5.5 where it correct to capitalize it.
>>>> 
>>>> BGP Speaker
>>>> 
>>>> BGP-LS Attribute
>>>> BGP-LS Speaker
>>>> -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 18) <!-- [rfced] FYI - We have added expansions for the following
>>>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide").
>>>> Please
>>>> review each expansion in the document carefully to ensure
>>>> correctness.
>>>> 
>>>> Not-So-Stubby Area (NSSA)
>>>> Provider Edge (PE)
>>>> RSVP - Fast Reroute (RSVP-FRR)
>>>> -->
>>>> 
>>>> KT> Yes
>>>> 
>>>> 
>>>> 
>>>> 19) <!-- [rfced] Please review the "Inclusive Language" portion of
>>>> the
>>>> online Style Guide <https://www.rfc-
>>>> editor.org/styleguide/part2/#inclusive_language>
>>>> and let us know if any changes are needed.
>>>> 
>>>> Note that our script did not flag any words in particular, but this
>>>> should
>>>> still be reviewed as a best practice.
>>>> -->
>>>> 
>>>> KT> Ack
>>>> 
>>>> Thanks,
>>>> Ketan
>>>> 
>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor
>>>> 
>>>> On Dec 15, 2023, at 6:10 PM, [e-mail] wrote:
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2023/12/15
>>>> 
>>>> 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://www.rfc-editor.org/faq/).
>>>> 
>>>> 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://trustee.ietf.org/license-info/).
>>>> 
>>>> *  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://authors.ietf.org/rfcxml-vocabulary>.
>>>> 
>>>> *  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
>>>> 
>>>> *  [e-mail] (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).
>>>> 
>>>> *  [e-mail], which is a new archival mailing
>>>> list
>>>>   to preserve AUTH48 conversations; it is not an active discussion
>>>>  list:
>>>> 
>>>> *  More info:
>>>>   https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-
>>>> 4Q9l2USxIAe6P8O4Zc
>>>> 
>>>> *  The archive itself:
>>>>   https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>> 
>>>> *  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,
>>>>   [e-mail] 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://www.rfc-editor.org/authors/rfc9552.xml
>>>>   https://www.rfc-editor.org/authors/rfc9552.html
>>>>   https://www.rfc-editor.org/authors/rfc9552.pdf
>>>>   https://www.rfc-editor.org/authors/rfc9552.txt
>>>> 
>>>> Diff file of the text:
>>>>   https://www.rfc-editor.org/authors/rfc9552-diff.html
>>>>   https://www.rfc-editor.org/authors/rfc9552-rfcdiff.html (side by
>>>> side)
>>>> 
>>>> Diff of the XML:
>>>>  https://www.rfc-editor.org/authors/rfc9552-xmldiff1.html
>>>> 
>>>> The following files are provided to facilitate creation of your own
>>>> diff files of the XML.
>>>> 
>>>> Initial XMLv3 created using XMLv2 as input:
>>>>    https://www.rfc-editor.org/authors/rfc9552.original.v2v3.xml
>>>> 
>>>> XMLv3 file that is a best effort to capture v3-related format
>>>> updates
>>>> only:
>>>>  https://www.rfc-editor.org/authors/rfc9552.form.xml
>>>> 
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>>   https://www.rfc-editor.org/auth48/rfc9552
>>>> 
>>>> Please let us know if you have any questions.
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9552 (draft-ietf-idr-rfc7752bis-17)
>>>> 
>>>> Title            : Distribution of Link-State and Traffic
>>>> Engineering Information Using BGP
>>>> Author(s)        : K. Talaulikar, Ed.
>>>> WG Chair(s)      : Susan Hares, Keyur Patel, Jeffrey Haas
>>>> 
>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>>>> 
>>>> 
>>> 
>