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

[Alanna Paloma <[e-mail]>]

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 visibility of more than one TED"  and "requires CPU-intensive or coordinated computations" are the two OR clauses referring 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 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-bit width and hence it was abbreviated to "Route Type". We can 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) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) defined 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 (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
> > 
> > 
>