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

[[e-mail]]

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.
-->


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.
-->   


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.
-->   


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>? 
-->


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'.
-->


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             |                   |
-->


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:
-->   


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? 
-->


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
-->     


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].
-->   


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"?
-->


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.
-->    


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.
-->   


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].
-->


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.
-->   


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

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

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?
BGP Speaker

BGP-LS Attribute
BGP-LS Speaker
-->


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)
-->


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.
-->


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