Re: [auth48] AUTH48: RFC-to-be 9352 <draft-ietf-lsr-isis-srv6-extensions-19> for your review

[Peter Psenak <[e-mail]>]

Hi,

thanks for the changes, please see my responses inline (##PP):

On 26/01/2023 22:34, [e-mail] wrote:
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!--[rfced] The title of the document has been updated as follows
> (note that we updated "Dataplane" to "Data Plane" for consistency
> and to match use in RFC 9350).  Please review.
> 
> Original:
>     IS-IS Extensions to Support Segment Routing over IPv6 Dataplane
> 
> Current:
>     IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane
> -->

##PP
Ack
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->
> 
> 
> 3) <!--[rfced] We notice "router capabilities TLV" vs. "Router
> Capabilities TLV", so we updated as "Router Capability TLV" to
> match use in RFC 9350. However, we also note that RFC 7981 only
> uses "IS-IS Router CAPABILITY TLV". Should the instances of
> "Router Capability TLV" perhaps be updated to reflect use in
> RFC 7981, or is the current text below okay as is?

##PP
"Router Capability TLV" is good.

> 
> Current:
>     A node indicates that it supports the SR Segment Endpoint
>     Node functionality as specified in [RFC8754] by advertising
>     a new SRv6 Capabilities sub-TLV of the Router Capability
>     TLV [RFC7981].
> 
> Current:
>     [RFC8491] defines the means to advertise node-/link-specific
>     values for MSDs of various types. Node MSDs are advertised in
>     a sub-TLV of the Router Capability TLV [RFC7981].
> -->

##PP
Ack
> 
> 
> 4) <!--[rfced] FYI: For the second figure in Section 2, the alignment of
> the bit ruler has been corrected.
> -->

##PP
thanks
> 
> 
> 5) <!--[rfced] Since "algorithm(s)" is read as singular, we updated the
> text as follows. Please let us know of any concerns.
> 
> Original:
>     An SRv6 capable router indicates supported algorithm(s)
>     by advertising the Segment Routing Algorithm sub-TLV as
>     defined in [RFC8667].
> 
> Current:
>     An SRv6-capable router indicates one or more supported
>     algorithms by advertising the Segment Routing Algorithm
>     sub-TLV, as defined in [RFC8667].
> -->

##PP
Ack
> 
> 
> 6) <!--[rfced] We note that "D-flag" is not described in RFC 5305. Is an
> updated needed, or does "D-flag" perhaps refer to the "up/down
> bit" in RFC 5305?

##PP
referring to it as "up/down bit" in RFC 5305 is fine. But keep the name 
of the bit as D-flag.

> 
> Original:
>     D-flag: Same as described in section 4.1. of [RFC5305].
> -->
> 
> 
> 7) <!--[rfced] Since Table 1 (Section 10) is the only table without a
> title, would you like to add one - perhaps "Endpoint Behaviors"
> or other?

##PP
yes, "Endpoint Behaviors" is fine.

> -->
> 
> 
> 8) <!--[rfced] We have included some specific questions about the IANA
> text below. In addition to responding to those questions, please
> review all of the IANA-related updates carefully and let us know
> if any further updates are needed.

##PP
I feel the first paragraph in section 11.1.1 should be moved to section 
11.1 as it is related to SRv6 Locator TLV, not the SRv6 End SID Sub-TLV.

Section 11.4, for type 43 in description it says "SRv6 End.X SI", please 
update to "SRv6 End.X SID"

> 
> 1) FYI: IANA has indicated that the authors approved removing "TLV"
> from the names/descriptions.  Given this, we have removed "TLV" below
> (which now matches the "IS-IS Top-Level TLV Codepoints" registry at
> https://www.iana.org/assignments/isis-tlv-codepoints/).
> 
> Original:
>     Type | Description      | IIH | LSP | SNP | Purge
>     27   | SRv6 Locator TLV | n   | y   |n    | n
> 
> Current:
>     Value | Name            | IIH | LSP | SNP | Purge
>     27    | SRv6 Locator    | n   | y   |n    | n

##PP
Ack

> 
> 2) Section 11.1.2. In Table 4, should the "Description" column be added
> for clarity? Also, should only column 27 be included since that is the
> only new information being added (i.e., should columns 135, 235, 236,
> and 237 be deleted)?
> -->

##PP
- I'm fine adding the "Description" column
- in terms of only including the column 27, I feel it is easier to 
understand if we include the whole table.

> 
> 
> 9) <!-- [rfced] 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.
> 
> - SRv6 Capability sub-TLV vs. SRv6 Capabilities sub-TLV
>      Note:
>      Are these terms different? We notice that Section 11.3
>      refers to "the SRv6 Capability sub-TLV specified in this
>      document (Section 2)", and Section 11.8 refers to
>      "the IS-IS SRv6 Capabilities sub-TLV specified in this
>      document (Section 2)". However, Section 2 refers to the
>      "SRv6 Capabilities sub-TLV". Please let us know how we
>      may update this for consistency.

it is the same thing, please use "SRv6 Capabilities sub-TLV" everywhere

> 
> - sub-TLV vs. Sub-TLV
> - sub-sub-TLV vs. Sub-sub-TLV vs. Sub-Sub-TLV
>      Note: To match RFCs 9350 and 9351, we will make "sub-TLV" and
>      "sub-sub-TLV" lowercase in the text, and they will be capitalized
>      in section titles and registry names.  Please let us know of any
>      concerns before we proceed with the updates as appropriate.
> -->
##PP
Ack

> 
> 
> 10) <!-- [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.
> 
> For example, please consider whether "black-holed" should be updated.

##PP
please replace the "black-holed" with "dropped"


thanks,
Peter

> -->
> 
> 
> Thank you.
> 
> RFC Editor/ap/kc
> 
> 
> On Jan 26, 2023, at 1:32 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2023/01/26
> 
> 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/rfc9352.xml
>    https://www.rfc-editor.org/authors/rfc9352.html
>    https://www.rfc-editor.org/authors/rfc9352.pdf
>    https://www.rfc-editor.org/authors/rfc9352.txt
> 
> Diff file of the text:
>    https://www.rfc-editor.org/authors/rfc9352-diff.html
>    https://www.rfc-editor.org/authors/rfc9352-rfcdiff.html (side by side)
> 
> Diff of the XML:
>    https://www.rfc-editor.org/authors/rfc9352-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/rfc9352.original.v2v3.xml
> 
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>    https://www.rfc-editor.org/authors/rfc9352.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>    https://www.rfc-editor.org/auth48/rfc9352
> 
> Please let us know if you have any questions.
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9352 (draft-ietf-lsr-isis-srv6-extensions-19)
> 
> Title            : IS-IS Extensions to Support Segment Routing over IPv6 Dataplane
> Author(s)        : P. Psenak, Ed., C. Filsfils, A. Bashandy, B. Decraene, Z. Hu
> WG Chair(s)      : Acee Lindem, Christian Hopps
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> 
> 
> 
>