Re: [auth48] [IANA #1283317] [IANA] Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Sabrina.  Looks great!  Thank you!

RFC Editor/lb

> On Oct 6, 2023, at 2:58 PM, Sabrina Tanamal via RT <[e-mail]> wrote:
> 
> Hi Lynne, 
> 
> These changes are complete: 
> 
> https://www.iana.org/assignments/isis-tlv-codepoints
> https://www.iana.org/assignments/igp-parameters
> 
> Thanks,
> Sabrina
> 
> On Thu Oct 05 17:04:59 2023, [e-mail] wrote:
>> Dear IANA,
>> 
>> We are preparing this document for publication.  Please make the
>> following updates per this document (https://www.rfc-
>> editor.org/authors/rfc9479.txt):
>> 
>> 1) Please make the following updates on
>> <https://www.iana.org/assignments/isis-tlv-codepoints/>:
>> 
>> OLD:
>>  18 TE Default Metric [RFC5305]
>> 
>> NEW (in the "IS-IS Sub-Sub-TLV Codepoints for Application-Specific
>> Link Attributes" registry -- per RFC 5305):
>> 18 TE Default metric [RFC5305]
>> 
>> OLD:
>> Description
>>    This registry defines sub-TLVs for Application Specific SRLG TLV
>> (238).
>> 
>> NEW (in the "IS-IS Sub-TLVs for Application-Specific SRLG TLV"
>> registry -- add a hyphen to "Application Specific"):
>> Description
>>    This registry defines sub-TLVs for the Application-Specific SRLG
>> TLV (TLV 238).
>> 
>> = = = = =
>> 
>> 2) Per Table 6 in this document, please add a hyphen to "Loop Free" in
>> "Loop Free Alternate (F-bit)" in the "Link Attribute Application
>> Identifiers" registry on <https://www.iana.org/assignments/igp-
>> parameters/>:
>> 
>> OLD:
>> 2    Loop Free Alternate (F-bit)    [RFC-ietf-lsr-rfc8919bis-04]
>> 
>> NEW:
>> 2    Loop-Free Alternate (F-bit)    [RFC-ietf-lsr-rfc8919bis-04]
>> 
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Oct 4, 2023, at 1:41 PM, Lynne Bartholomew <[e-mail]>
>>> wrote:
>>> 
>>> Hi, Acee.  So noted on <https://www.rfc-editor.org/auth48/rfc9479>.
>>> Thank you!
>>> 
>>> RFC Editor/lb
>>> 
>>>> On Oct 4, 2023, at 1:13 PM, Acee Lindem <[e-mail]> wrote:
>>>> 
>>>> I forgot to mention - this version looks good to me.
>>>> 
>>>> Thanks,
>>>> Acee
>>>> 
>>>>> On Oct 4, 2023, at 12:54 PM, Lynne Bartholomew
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Hi, Acee.  I'll let the editor of RFC 9492 know.  Thank you!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>>> On Oct 4, 2023, at 9:47 AM, Acee Lindem <[e-mail]>
>>>>>> wrote:
>>>>>> 
>>>>>> Hi Lynne,
>>>>>> 
>>>>>>> On Oct 4, 2023, at 12:27, Lynne Bartholomew
>>>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi, Acee.  No worries, and thank you for aligning the wording in
>>>>>>> this document with RFC 9492!
>>>>>>> 
>>>>>>> Because we changed "introducing new backwards-compatibility
>>>>>>> issues" to "introducing backwards-compatibility issues" in this
>>>>>>> document, please confirm that "introducing new backwards-
>>>>>>> compatibility issues" in RFC 9492 is as desired.
>>>>>> 
>>>>>> 
>>>>>> I’d remove it from RFC 9492 as well. It is correct both ways but
>>>>>> “introducing” implies “new” so it is redundant.
>>>>>> 
>>>>>> Thanks,
>>>>>> Acee
>>>>>> 
>>>>>>> 
>>>>>>> The latest files for this document are posted here (please
>>>>>>> refresh your browser):
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9479-auth48diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastrfcdiff.html
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html
>>>>>>> 
>>>>>>> Thanks again!
>>>>>>> 
>>>>>>> RFC Editor/lb
>>>>>>> 
>>>>>>>> On Oct 3, 2023, at 10:35 AM, Acee Lindem <[e-mail]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Thanks Lynne - apologies but I neglected to remove some of the
>>>>>>>> instances of “new” which are no longer new.
>>>>>>>> 
>>>>>>>> *** rfc9479.txt.orig Tue Oct  3 13:31:44 2023
>>>>>>>> --- rfc9479.txt Tue Oct  3 13:33:15 2023
>>>>>>>> ***************
>>>>>>>> *** 189,195 ****
>>>>>>>> attributes may grow in the future, an additional requirement is
>>>>>>>> that
>>>>>>>> the extensions defined allow the association of additional
>>>>>>>> applications to link attributes without altering the format of
>>>>>>>> the
>>>>>>>> !    advertisements or introducing new backwards-compatibility
>>>>>>>> issues.
>>>>>>>> 
>>>>>>>> Finally, there may still be many cases where a single attribute
>>>>>>>> value
>>>>>>>> can be shared among multiple applications, so the solution must
>>>>>>>> --- 189,195 ----
>>>>>>>> attributes may grow in the future, an additional requirement is
>>>>>>>> that
>>>>>>>> the extensions defined allow the association of additional
>>>>>>>> applications to link attributes without altering the format of
>>>>>>>> the
>>>>>>>> !    advertisements or introducing backwards-compatibility
>>>>>>>> issues.
>>>>>>>> 
>>>>>>>> Finally, there may still be many cases where a single attribute
>>>>>>>> value
>>>>>>>> can be shared among multiple applications, so the solution must
>>>>>>>> ***************
>>>>>>>> *** 254,260 ****
>>>>>>>> 
>>>>>>>> 4.  Advertising Application-Specific Link Attributes
>>>>>>>> 
>>>>>>>> !    Two new codepoints are defined to support Application-
>>>>>>>> Specific Link
>>>>>>>> Attribute (ASLA) advertisements:
>>>>>>>> 
>>>>>>>> 1.  Application-Specific Link Attributes sub-TLV for TLVs
>>>>>>>> Advertising
>>>>>>>> --- 254,260 ----
>>>>>>>> 
>>>>>>>> 4.  Advertising Application-Specific Link Attributes
>>>>>>>> 
>>>>>>>> !    Two codepoints are defined to support Application-Specific
>>>>>>>> Link
>>>>>>>> Attribute (ASLA) advertisements:
>>>>>>>> 
>>>>>>>> 1.  Application-Specific Link Attributes sub-TLV for TLVs
>>>>>>>> Advertising
>>>>>>>> ***************
>>>>>>>> *** 272,285 ****
>>>>>>>> not subject to standardization and are outside the scope of this
>>>>>>>> document.
>>>>>>>> 
>>>>>>>> !    The following sections define the format of these new
>>>>>>>> advertisements.
>>>>>>>> 
>>>>>>>> 4.1.  Application Identifier Bit Mask
>>>>>>>> 
>>>>>>>> Identification of the set of applications associated with link
>>>>>>>> attribute advertisements utilizes two bit masks.  One bit mask
>>>>>>>> is for
>>>>>>>> standard applications where the definition of each bit is
>>>>>>>> defined in
>>>>>>>> !    a new IANA-controlled registry (see Section 7.4).  A second
>>>>>>>> bit mask
>>>>>>>> is for non-standard UDAs.
>>>>>>>> 
>>>>>>>> The encoding defined below is used by both the Application-
>>>>>>>> Specific
>>>>>>>> --- 272,285 ----
>>>>>>>> not subject to standardization and are outside the scope of this
>>>>>>>> document.
>>>>>>>> 
>>>>>>>> !    The following sections define the format of these
>>>>>>>> advertisements.
>>>>>>>> 
>>>>>>>> 4.1.  Application Identifier Bit Mask
>>>>>>>> 
>>>>>>>> Identification of the set of applications associated with link
>>>>>>>> attribute advertisements utilizes two bit masks.  One bit mask
>>>>>>>> is for
>>>>>>>> standard applications where the definition of each bit is
>>>>>>>> defined in
>>>>>>>> !    an IANA-controlled registry (see Section 7.4).  A second
>>>>>>>> bit mask
>>>>>>>> is for non-standard UDAs.
>>>>>>>> 
>>>>>>>> The encoding defined below is used by both the Application-
>>>>>>>> Specific
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Acee
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Oct 3, 2023, at 1:13 PM, Lynne Bartholomew
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Hi, Acee, Peter, Wim, and Stefano.
>>>>>>>>> 
>>>>>>>>> Acee, we have updated this document per your notes below.
>>>>>>>>> 
>>>>>>>>> The latest files are posted here (please refresh your browser):
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-auth48diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastdiff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastrfcdiff.html
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html
>>>>>>>>> 
>>>>>>>>> Peter, Wim, and Stefano, we have noted your approvals on the
>>>>>>>>> AUTH48 status page:
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9479
>>>>>>>>> 
>>>>>>>>> We now have all author approvals for this document.  We will
>>>>>>>>> ask IANA to (1) confirm that all references to RFC 8919 in
>>>>>>>>> their registries now point to this document and (2) make
>>>>>>>>> additional updates, as applicable, to match this document.
>>>>>>>>> After those changes are complete, we will prepare this document
>>>>>>>>> for publication.
>>>>>>>>> 
>>>>>>>>> Thank you!
>>>>>>>>> 
>>>>>>>>> RFC Editor/lb
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Oct 1, 2023, at 2:25 AM, Stefano Previdi
>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> I also approve the publication.
>>>>>>>>>> 
>>>>>>>>>> Thanks.
>>>>>>>>>> s.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Sep 30, 2023, at 9:57 PM, Wim Henderickx (Nokia)
>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> I also approve
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Sep 30, 2023, at 2:47 AM, Peter Psenak <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Lynne,
>>>>>>>>>> 
>>>>>>>>>> you have my approval as well.
>>>>>>>>>> 
>>>>>>>>>> thanks,
>>>>>>>>>> Peter
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Sep 29, 2023, at 1:32 PM, Acee Lindem <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Les, Lynne,
>>>>>>>>>> 
>>>>>>>>>> Here are the edits analogous to those I request for RFC 9492.
>>>>>>>>>> Mostly, removing “new” where it is redundant.
>>>>>>>>>> 
>>>>>>>>>> *** rfc9479.txt.orig Fri Sep 29 16:29:06 2023
>>>>>>>>>> --- rfc9479.txt Fri Sep 29 16:26:23 2023
>>>>>>>>>> ***************
>>>>>>>>>> *** 27,33 ****
>>>>>>>>>> attributes, the current advertisements do not support
>>>>>>>>>> application-
>>>>>>>>>> specific values for a given attribute, nor do they support an
>>>>>>>>>> indication of which applications are using the advertised
>>>>>>>>>> value for a
>>>>>>>>>> !    given link.  This document introduces new link attribute
>>>>>>>>>> advertisements that address both of these shortcomings.
>>>>>>>>>> 
>>>>>>>>>> This document obsoletes RFC 8919.
>>>>>>>>>> --- 27,33 ----
>>>>>>>>>> attributes, the current advertisements do not support
>>>>>>>>>> application-
>>>>>>>>>> specific values for a given attribute, nor do they support an
>>>>>>>>>> indication of which applications are using the advertised
>>>>>>>>>> value for a
>>>>>>>>>> !    given link.  This document introduces link attribute
>>>>>>>>>> advertisements that address both of these shortcomings.
>>>>>>>>>> 
>>>>>>>>>> This document obsoletes RFC 8919.
>>>>>>>>>> ***************
>>>>>>>>>> *** 137,143 ****
>>>>>>>>>> advertised for that link, it assumes that RSVP-TE is enabled
>>>>>>>>>> on that
>>>>>>>>>> link, even though it is not.  If such an RSVP-TE head-end
>>>>>>>>>> router
>>>>>>>>>> tries to set up an RSVP-TE path via that link, it will result
>>>>>>>>>> in a
>>>>>>>>>> !    path setup failure.
>>>>>>>>>> 
>>>>>>>>>> An additional issue arises in cases where both applications
>>>>>>>>>> are
>>>>>>>>>> supported on a link but the link attribute values associated
>>>>>>>>>> with
>>>>>>>>>> --- 137,143 ----
>>>>>>>>>> advertised for that link, it assumes that RSVP-TE is enabled
>>>>>>>>>> on that
>>>>>>>>>> link, even though it is not.  If such an RSVP-TE head-end
>>>>>>>>>> router
>>>>>>>>>> tries to set up an RSVP-TE path via that link, it will result
>>>>>>>>>> in a
>>>>>>>>>> !    setup failure for the path.
>>>>>>>>>> 
>>>>>>>>>> An additional issue arises in cases where both applications
>>>>>>>>>> are
>>>>>>>>>> supported on a link but the link attribute values associated
>>>>>>>>>> with
>>>>>>>>>> ***************
>>>>>>>>>> *** 262,268 ****
>>>>>>>>>> 
>>>>>>>>>> 2.  Application-Specific SRLG TLV (defined in Section 4.3).
>>>>>>>>>> 
>>>>>>>>>> !    To support these new advertisements, an application
>>>>>>>>>> identifier bit
>>>>>>>>>> mask is defined to identify the application(s) associated with
>>>>>>>>>> a
>>>>>>>>>> given advertisement (defined in Section 4.1).
>>>>>>>>>> 
>>>>>>>>>> --- 262,268 ----
>>>>>>>>>> 
>>>>>>>>>> 2.  Application-Specific SRLG TLV (defined in Section 4.3).
>>>>>>>>>> 
>>>>>>>>>> !    To support these advertisements, an application
>>>>>>>>>> identifier bit
>>>>>>>>>> mask is defined to identify the application(s) associated with
>>>>>>>>>> a
>>>>>>>>>> given advertisement (defined in Section 4.1).
>>>>>>>>>> 
>>>>>>>>>> ***************
>>>>>>>>>> *** 381,387 ****
>>>>>>>>>> 
>>>>>>>>>> 4.2.  Application-Specific Link Attributes Sub-TLV
>>>>>>>>>> 
>>>>>>>>>> !    A new sub-TLV for TLVs Advertising Neighbor Information
>>>>>>>>>> is defined
>>>>>>>>>> that supports specification of the applications and
>>>>>>>>>> application-
>>>>>>>>>> specific attribute values.
>>>>>>>>>> 
>>>>>>>>>> --- 381,387 ----
>>>>>>>>>> 
>>>>>>>>>> 4.2.  Application-Specific Link Attributes Sub-TLV
>>>>>>>>>> 
>>>>>>>>>> !    A sub-TLV for TLVs Advertising Neighbor Information is
>>>>>>>>>> defined
>>>>>>>>>> that supports specification of the applications and
>>>>>>>>>> application-
>>>>>>>>>> specific attribute values.
>>>>>>>>>> 
>>>>>>>>>> ***************
>>>>>>>>>> *** 439,445 ****
>>>>>>>>>> Application Identifier Bit set are present for a given link.
>>>>>>>>>> Otherwise, such link attribute advertisements MUST NOT be
>>>>>>>>>> used.
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a new registry of sub-sub-TLVs to define
>>>>>>>>>> the link
>>>>>>>>>> attribute sub-sub-TLV codepoints (see Section 7.3).  This
>>>>>>>>>> document
>>>>>>>>>> defines a sub-sub-TLV for each of the existing sub-TLVs listed
>>>>>>>>>> in
>>>>>>>>>> Section 3.1, except as noted below.  The format of the sub-
>>>>>>>>>> sub-TLVs
>>>>>>>>>> --- 439,445 ----
>>>>>>>>>> Application Identifier Bit set are present for a given link.
>>>>>>>>>> Otherwise, such link attribute advertisements MUST NOT be
>>>>>>>>>> used.
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a registry of sub-sub-TLVs to define the
>>>>>>>>>> link
>>>>>>>>>> attribute sub-sub-TLV codepoints (see Section 7.3).  This
>>>>>>>>>> document
>>>>>>>>>> defines a sub-sub-TLV for each of the existing sub-TLVs listed
>>>>>>>>>> in
>>>>>>>>>> Section 3.1, except as noted below.  The format of the sub-
>>>>>>>>>> sub-TLVs
>>>>>>>>>> ***************
>>>>>>>>>> *** 464,470 ****
>>>>>>>>>> 
>>>>>>>>>> It is also possible to advertise a single advertisement with a
>>>>>>>>>> zero-
>>>>>>>>>> length SABM and UDABM so long as the constraints discussed in
>>>>>>>>>> !    Sections 4.2 and 6.2 are acceptable.
>>>>>>>>>> 
>>>>>>>>>> If different values for maximum link bandwidth for a given
>>>>>>>>>> link are
>>>>>>>>>> advertised, all values MUST be ignored.
>>>>>>>>>> --- 464,470 ----
>>>>>>>>>> 
>>>>>>>>>> It is also possible to advertise a single advertisement with a
>>>>>>>>>> zero-
>>>>>>>>>> length SABM and UDABM so long as the constraints discussed in
>>>>>>>>>> !    Sections 4.2 and 6.2 are satisfied.
>>>>>>>>>> 
>>>>>>>>>> If different values for maximum link bandwidth for a given
>>>>>>>>>> link are
>>>>>>>>>> advertised, all values MUST be ignored.
>>>>>>>>>> ***************
>>>>>>>>>> *** 497,505 ****
>>>>>>>>>> 
>>>>>>>>>> 4.3.  Application-Specific SRLG TLV
>>>>>>>>>> 
>>>>>>>>>> !    A new TLV is defined to advertise application-specific
>>>>>>>>>> SRLGs for a
>>>>>>>>>> given link.  Although similar in functionality to TLV 138
>>>>>>>>>> [RFC5307]
>>>>>>>>>> !    and TLV 139 [RFC6119], this new single TLV provides
>>>>>>>>>> support for IPv4,
>>>>>>>>>> IPv6, and unnumbered identifiers for a link.  Unlike TLVs 138
>>>>>>>>>> and
>>>>>>>>>> 139, it utilizes sub-TLVs to encode the link identifiers in
>>>>>>>>>> order to
>>>>>>>>>> provide the flexible formatting required to support multiple
>>>>>>>>>> link
>>>>>>>>>> --- 497,505 ----
>>>>>>>>>> 
>>>>>>>>>> 4.3.  Application-Specific SRLG TLV
>>>>>>>>>> 
>>>>>>>>>> !    A TLV is defined to advertise application-specific SRLGs
>>>>>>>>>> for a
>>>>>>>>>> given link.  Although similar in functionality to TLV 138
>>>>>>>>>> [RFC5307]
>>>>>>>>>> !    and TLV 139 [RFC6119], this single TLV provides support
>>>>>>>>>> for IPv4,
>>>>>>>>>> IPv6, and unnumbered identifiers for a link.  Unlike TLVs 138
>>>>>>>>>> and
>>>>>>>>>> 139, it utilizes sub-TLVs to encode the link identifiers in
>>>>>>>>>> order to
>>>>>>>>>> provide the flexible formatting required to support multiple
>>>>>>>>>> link
>>>>>>>>>> ***************
>>>>>>>>>> *** 758,764 ****
>>>>>>>>>> This section lists the protocol codepoint changes introduced
>>>>>>>>>> by this
>>>>>>>>>> document and the related IANA updates.
>>>>>>>>>> 
>>>>>>>>>> !    For the new registries defined under the "IS-IS TLV
>>>>>>>>>> Codepoints" group
>>>>>>>>>> of registries with a registration procedure of "Expert Review"
>>>>>>>>>> (see
>>>>>>>>>> Sections 7.3 and 7.5), guidance for designated experts can be
>>>>>>>>>> found
>>>>>>>>>> in [RFC7370].
>>>>>>>>>> --- 758,764 ----
>>>>>>>>>> This section lists the protocol codepoint changes introduced
>>>>>>>>>> by this
>>>>>>>>>> document and the related IANA updates.
>>>>>>>>>> 
>>>>>>>>>> !    For the registries defined under the "IS-IS TLV
>>>>>>>>>> Codepoints" group
>>>>>>>>>> of registries with a registration procedure of "Expert Review"
>>>>>>>>>> (see
>>>>>>>>>> Sections 7.3 and 7.5), guidance for designated experts can be
>>>>>>>>>> found
>>>>>>>>>> in [RFC7370].
>>>>>>>>>> ***************
>>>>>>>>>> *** 768,774 ****
>>>>>>>>>> 
>>>>>>>>>> 7.1.  Application-Specific Link Attributes Sub-TLV
>>>>>>>>>> 
>>>>>>>>>> !    IANA has registered the new sub-TLV defined in Section
>>>>>>>>>> 4.2 in the
>>>>>>>>>> "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information"
>>>>>>>>>> registry.
>>>>>>>>>> 
>>>>>>>>>> +======+======================+====+====+======+=====+=====+=====+
>>>>>>>>>> --- 768,774 ----
>>>>>>>>>> 
>>>>>>>>>> 7.1.  Application-Specific Link Attributes Sub-TLV
>>>>>>>>>> 
>>>>>>>>>> !    IANA has registered the sub-TLV defined in Section 4.2 in
>>>>>>>>>> the
>>>>>>>>>> "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information"
>>>>>>>>>> registry.
>>>>>>>>>> 
>>>>>>>>>> +======+======================+====+====+======+=====+=====+=====+
>>>>>>>>>> ***************
>>>>>>>>>> *** 782,788 ****
>>>>>>>>>> 
>>>>>>>>>> 7.2.  Application-Specific SRLG TLV
>>>>>>>>>> 
>>>>>>>>>> !    IANA has registered the new TLV defined in Section 4.3 in
>>>>>>>>>> the "IS-IS
>>>>>>>>>> Top-Level TLV Codepoints" registry.
>>>>>>>>>> 
>>>>>>>>>> +=======+===========================+=====+=====+=====+=======+
>>>>>>>>>> --- 782,788 ----
>>>>>>>>>> 
>>>>>>>>>> 7.2.  Application-Specific SRLG TLV
>>>>>>>>>> 
>>>>>>>>>> !    IANA has registered the TLV defined in Section 4.3 in the
>>>>>>>>>> "IS-IS
>>>>>>>>>> Top-Level TLV Codepoints" registry.
>>>>>>>>>> 
>>>>>>>>>> +=======+===========================+=====+=====+=====+=======+
>>>>>>>>>> ***************
>>>>>>>>>> *** 796,802 ****
>>>>>>>>>> 7.3.  IS-IS Sub-Sub-TLV Codepoints for Application-Specific
>>>>>>>>>> Link
>>>>>>>>>> Attributes Registry
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a new registry titled "IS-IS Sub-Sub-TLV
>>>>>>>>>> Codepoints
>>>>>>>>>> for Application-Specific Link Attributes" under the "IS-IS TLV
>>>>>>>>>> Codepoints" registry to control the assignment of sub-sub-TLV
>>>>>>>>>> codepoints for the Application-Specific Link Attributes sub-
>>>>>>>>>> TLV
>>>>>>>>>> --- 796,802 ----
>>>>>>>>>> 7.3.  IS-IS Sub-Sub-TLV Codepoints for Application-Specific
>>>>>>>>>> Link
>>>>>>>>>> Attributes Registry
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a registry titled "IS-IS Sub-Sub-TLV
>>>>>>>>>> Codepoints
>>>>>>>>>> for Application-Specific Link Attributes" under the "IS-IS TLV
>>>>>>>>>> Codepoints" registry to control the assignment of sub-sub-TLV
>>>>>>>>>> codepoints for the Application-Specific Link Attributes sub-
>>>>>>>>>> TLV
>>>>>>>>>> ***************
>>>>>>>>>> *** 863,869 ****
>>>>>>>>>> 
>>>>>>>>>> 7.4.  Link Attribute Application Identifiers Registry
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a new registry titled "Link Attribute
>>>>>>>>>> Application
>>>>>>>>>> Identifiers" within the "Interior Gateway Protocol (IGP)
>>>>>>>>>> Parameters"
>>>>>>>>>> group of registries to control the assignment of Application
>>>>>>>>>> Identifier Bits.  The registration policy for this registry is
>>>>>>>>>> --- 863,869 ----
>>>>>>>>>> 
>>>>>>>>>> 7.4.  Link Attribute Application Identifiers Registry
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a registry titled "Link Attribute
>>>>>>>>>> Application
>>>>>>>>>> Identifiers" within the "Interior Gateway Protocol (IGP)
>>>>>>>>>> Parameters"
>>>>>>>>>> group of registries to control the assignment of Application
>>>>>>>>>> Identifier Bits.  The registration policy for this registry is
>>>>>>>>>> ***************
>>>>>>>>>> *** 889,895 ****
>>>>>>>>>> 
>>>>>>>>>> 7.5.  IS-IS Sub-TLVs for Application-Specific SRLG TLV
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a new registry titled "IS-IS Sub-TLVs
>>>>>>>>>> for
>>>>>>>>>> Application-Specific SRLG TLV" under the "IS-IS TLV
>>>>>>>>>> Codepoints"
>>>>>>>>>> registry to control the assignment of sub-TLV types for the
>>>>>>>>>> Application-Specific SRLG TLV (TLV 238).  The registration
>>>>>>>>>> procedure
>>>>>>>>>> --- 889,895 ----
>>>>>>>>>> 
>>>>>>>>>> 7.5.  IS-IS Sub-TLVs for Application-Specific SRLG TLV
>>>>>>>>>> 
>>>>>>>>>> !    IANA has created a registry titled "IS-IS Sub-TLVs for
>>>>>>>>>> Application-Specific SRLG TLV" under the "IS-IS TLV
>>>>>>>>>> Codepoints"
>>>>>>>>>> registry to control the assignment of sub-TLV types for the
>>>>>>>>>> Application-Specific SRLG TLV (TLV 238).  The registration
>>>>>>>>>> procedure
>>>>>>>>>> ***************
>>>>>>>>>> *** 938,944 ****
>>>>>>>>>> deployments, the stronger authentication mechanisms defined in
>>>>>>>>>> the
>>>>>>>>>> aforementioned documents SHOULD be used.
>>>>>>>>>> 
>>>>>>>>>> !    This document defines a new way to advertise link
>>>>>>>>>> attributes.
>>>>>>>>>> Tampering with the information defined in this document may
>>>>>>>>>> have an
>>>>>>>>>> effect on applications using it, including impacting TE as
>>>>>>>>>> discussed
>>>>>>>>>> in [RFC8570].  As the advertisements defined in this document
>>>>>>>>>> limit
>>>>>>>>>> --- 938,944 ----
>>>>>>>>>> deployments, the stronger authentication mechanisms defined in
>>>>>>>>>> the
>>>>>>>>>> aforementioned documents SHOULD be used.
>>>>>>>>>> 
>>>>>>>>>> !    This document defines an improved way to advertise link
>>>>>>>>>> attributes.
>>>>>>>>>> Tampering with the information defined in this document may
>>>>>>>>>> have an
>>>>>>>>>> effect on applications using it, including impacting TE as
>>>>>>>>>> discussed
>>>>>>>>>> in [RFC8570].  As the advertisements defined in this document
>>>>>>>>>> limit
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Acee
>>>>>>>>>> 
>>>>>>>>>>> On Sep 28, 2023, at 6:15 PM, Les Ginsberg (ginsberg)
>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Lynne -
>>>>>>>>>>> 
>>>>>>>>>>> Thanx for the clarification.
>>>>>>>>>>> I still prefer no table names - I can live with the format
>>>>>>>>>>> limitations.
>>>>>>>>>>> 
>>>>>>>>>>> Les
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>>>>>>>> Sent: Thursday, September 28, 2023 1:49 PM
>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>
>>>>>>>>>>>> Cc: Acee Lindem <[e-mail]>; rfc-editor@rfc-
>>>>>>>>>>>> editor.org; Peter
>>>>>>>>>>>> Psenak (ppsenak) <[e-mail]>; [e-mail];
>>>>>>>>>>>> [e-mail]; [e-mail]; lsr-
>>>>>>>>>>>> [e-mail]; lsr-
>>>>>>>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>>>>>>>> auth48archive@rfc-
>>>>>>>>>>>> editor.org
>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
>>>>>>>>>>>> rfc8919bis-04> for your
>>>>>>>>>>>> review
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi, Les.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you for the clarification re. question 14)b) and the
>>>>>>>>>>>> erratum text.
>>>>>>>>>>>> 
>>>>>>>>>>>> As for the placement of the "Table X" lines in the PDF and
>>>>>>>>>>>> HTML files, this is a
>>>>>>>>>>>> feature of xml2rfc v3, and we're not able to center the
>>>>>>>>>>>> "Table X" lines in PDF or
>>>>>>>>>>>> HTML.
>>>>>>>>>>>> 
>>>>>>>>>>>> We know that the topic of table titles in this document was
>>>>>>>>>>>> covered earlier --
>>>>>>>>>>>> not to use any for this document -- but if the tables had
>>>>>>>>>>>> titles, this effect would
>>>>>>>>>>>> not be so jarring in the PDF and HTML files.
>>>>>>>>>>>> 
>>>>>>>>>>>> Please let us know what you think; we'll wait to hear from
>>>>>>>>>>>> you again before
>>>>>>>>>>>> noting your approval.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks for your patience!
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sep 27, 2023, at 3:10 PM, Les Ginsberg (ginsberg)
>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Lynne -
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I have checked all of the additional changes - they have
>>>>>>>>>>>>> all been completed to
>>>>>>>>>>>> my satisfaction.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> One minor formatting request -  the "Table X" titles
>>>>>>>>>>>>> associated with each
>>>>>>>>>>>> table appear centered in the .txt file - but are left
>>>>>>>>>>>> aligned (at the table
>>>>>>>>>>>> boundary) in the PDF and HTML files.
>>>>>>>>>>>>> Is it possible to have them centered in the PDF/HTML files
>>>>>>>>>>>>> as well?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In regards to Question 14b - sorry for overlooking that.
>>>>>>>>>>>>> When I began work on the bis version, I noted that the
>>>>>>>>>>>>> Errata that had been
>>>>>>>>>>>> filed had a cut and paste error - there actually were no
>>>>>>>>>>>> changes required to
>>>>>>>>>>>> Section 6.2 - but I had mistakenly cut and pasted the
>>>>>>>>>>>> changes for Section 4.2 a
>>>>>>>>>>>> second time as if they should also be applied to Section
>>>>>>>>>>>> 6.2.
>>>>>>>>>>>>> No one noticed this when discussing the Errata - and since
>>>>>>>>>>>>> the Errata is
>>>>>>>>>>>> formally marked as rejected (in favor of doing a bis version
>>>>>>>>>>>> of the RFC) I saw
>>>>>>>>>>>> no reason to correct the already rejected Errata.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Bravo to you for noticing this - but this is why there are
>>>>>>>>>>>>> no changes to
>>>>>>>>>>>> Section 6.2. 😊
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Other than the minor format correction mentioned above,
>>>>>>>>>>>>> this latest version
>>>>>>>>>>>> has my approval.
>>>>>>>>>>>>> Thanx for all that you do.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Les
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>>>>>>>>>> Sent: Wednesday, September 27, 2023 1:42 PM
>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>; Acee
>>>>>>>>>>>>>> Lindem
>>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>>> Cc: [e-mail]; Peter Psenak (ppsenak)
>>>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>>>>> [e-mail]; [e-mail];
>>>>>>>>>>>>>> [e-mail]; lsr-
>>>>>>>>>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>>>>>>>>>> [e-mail];
>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
>>>>>>>>>>>>>> rfc8919bis-04> for
>>>>>>>>>>>> your
>>>>>>>>>>>>>> review
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi, Les and Acee.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thank you for the emails.  Les, thank you for your
>>>>>>>>>>>>>> thorough review and
>>>>>>>>>>>> replies
>>>>>>>>>>>>>> to our questions.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Les, we took a look at the five most recent RFCs that
>>>>>>>>>>>>>> obsolete other RFCs
>>>>>>>>>>>>>> (RFCs 9399, 9411, 9436, 9438, and 9457) and found that in
>>>>>>>>>>>>>> all five cases
>>>>>>>>>>>> the
>>>>>>>>>>>>>> RFC or RFCs being obsoleted were listed under Informative
>>>>>>>>>>>>>> References. As
>>>>>>>>>>>> you
>>>>>>>>>>>>>> noted below, Informative Reference is indeed the
>>>>>>>>>>>>>> appropriate choice here as
>>>>>>>>>>>>>> well, and we've moved the listing accordingly.  Apologies
>>>>>>>>>>>>>> for any confusion.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please advise re. our question 14)b):
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> b) We see that the "NEW" text for Section 4.2 was
>>>>>>>>>>>>>>>> applied per
>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/errata/eid6630> but the
>>>>>>>>>>>>>>>> "NEW" text for
>>>>>>>>>>>>>>>> Section 6.2 was not.  Is this as desired (i.e., does
>>>>>>>>>>>>>>>> "subject to the
>>>>>>>>>>>>>>>> restrictions specified in Section 4.2" in the first
>>>>>>>>>>>>>>>> paragraph of
>>>>>>>>>>>>>>>> Section 6.2 handle the erratum information adequately?)?
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The latest files are posted here (please refresh your
>>>>>>>>>>>>>> browser):
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-auth48diff.html
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Please review our updates carefully, and let us know if
>>>>>>>>>>>>>> anything is incorrect
>>>>>>>>>>>> or
>>>>>>>>>>>>>> we missed anything.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks again!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> RFC Editor/lb
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Sep 26, 2023, at 8:11 AM, Les Ginsberg (ginsberg)
>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Acee -
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I agree - but at most this is only informational.
>>>>>>>>>>>>>>> The discussion of what changed from RFC 8919 is
>>>>>>>>>>>>>>> informative from a
>>>>>>>>>>>>>> historical perspective - and may be useful to implementors
>>>>>>>>>>>>>> who wrote code
>>>>>>>>>>>>>> based on RFC 8919 and want to check whether they need to
>>>>>>>>>>>>>> make any
>>>>>>>>>>>>>> changes to be conformant to RFC 9479, but RFC 9479 should
>>>>>>>>>>>>>> stand on its
>>>>>>>>>>>>>> own. If an implementor never knew of the existence of RFC
>>>>>>>>>>>>>> 8919 it should
>>>>>>>>>>>> not
>>>>>>>>>>>>>> matter.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> So maybe Informative Reference is the appropriate choice
>>>>>>>>>>>>>>> here?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Sep 26, 2023, at 7:55 AM, Acee Lindem
>>>>>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I think it is common practice to reference the obsoleted
>>>>>>>>>>>>>>> draft in the
>>>>>>>>>>>>>> “Differences from RFCxxxx” text.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Acee
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Sep 25, 2023, at 8:13 PM, Les Ginsberg (ginsberg)
>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> And one other issue, highlighted in the review of
>>>>>>>>>>>>>>> RFC8920bis (to become
>>>>>>>>>>>>>> RFC9492)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> References to:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [SEGMENT-ROUTING]
>>>>>>>>>>>>>>>   Filsfils, C., Talaulikar, K., Ed., Voyer, D.,
>>>>>>>>>>>>>>> Bogdanov,
>>>>>>>>>>>>>>>   A., and P. Mattes, "Segment Routing Policy
>>>>>>>>>>>>>>> Architecture",
>>>>>>>>>>>>>>>   RFC 9256, DOI 10.17487/RFC9256, July 2022,
>>>>>>>>>>>>>>>   <https://www.rfc-editor.org/info/rfc9256>.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Need to be changed to use [RFC9256].
>>>>>>>>>>>>>>> The name [SEGMENT_ROUTING] occurs because when RFC 8919
>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>> published RFC9256 did not exist - it was still in draft
>>>>>>>>>>>>>> form.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Sep 25, 2023, at 7:50 PM, Les Ginsberg (ginsberg)
>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> One correction to my responses:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Given that this document obsoletes RFC8919, it seems
>>>>>>>>>>>>>>> inappropriate to
>>>>>>>>>>>>>> include RFC 8919 as a reference at all.
>>>>>>>>>>>>>>> At a minimum, it seems odd to have an obsoleted document
>>>>>>>>>>>>>>> as a
>>>>>>>>>>>> Normative
>>>>>>>>>>>>>> Reference.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> What is the correct policy here?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> (Sorry for missing this earlier)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Sep 25, 2023, at 3:39 PM, Les Ginsberg (ginsberg)
>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Folks -
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Please find my responses to your questions inline below.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: [e-mail] <rfc-editor@rfc-
>>>>>>>>>>>>>>>> editor.org>
>>>>>>>>>>>>>>>> Sent: Monday, September 11, 2023 2:59 PM
>>>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>; Peter
>>>>>>>>>>>>>>>> Psenak
>>>>>>>>>>>> (ppsenak)
>>>>>>>>>>>>>>>> <[e-mail]>; [e-mail];
>>>>>>>>>>>> [e-mail];
>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail]; lsr-
>>>>>>>>>>>>>>>> [e-mail];
>>>>>>>>>>>>>>>> [e-mail]; [e-mail]; auth48archive@rfc-
>>>>>>>>>>>>>>>> editor.org
>>>>>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
>>>>>>>>>>>>>>>> rfc8919bis-04> for
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Authors,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> While reviewing this document during AUTH48, please
>>>>>>>>>>>>>>>> resolve (as
>>>>>>>>>>>>>> necessary)
>>>>>>>>>>>>>>>> the following questions, which are also in the XML file.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 1) <!-- [rfced] Please note that because the XML file
>>>>>>>>>>>>>>>> for this document
>>>>>>>>>>>>>>>> was submitted in "prepped" format, we created a
>>>>>>>>>>>>>>>> "nonprepped" copy of
>>>>>>>>>>>>>>>> the file in order to edit the document properly.  This
>>>>>>>>>>>>>>>> does not
>>>>>>>>>>>>>>>> impact the document's text but resulted in many changes
>>>>>>>>>>>>>>>> to the XML
>>>>>>>>>>>>>>>> code (as can be viewed in the "xmldiff" files that will
>>>>>>>>>>>>>>>> be provided
>>>>>>>>>>>>>>>> when this document moves to the AUTH48 state). -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] Understood. Out of an abundance of caution I
>>>>>>>>>>>>>>> started with the XML
>>>>>>>>>>>>>> available from Datatracker for RFC 8919. It had a number
>>>>>>>>>>>>>> of
>>>>>>>>>>>> "strangenesses"
>>>>>>>>>>>>>> (at least to me) - but I chose not to modify them as I
>>>>>>>>>>>>>> wanted the
>>>>>>>>>>>> text/format
>>>>>>>>>>>>>> to be as close as possible to RFC 8919.
>>>>>>>>>>>>>>> I wish there had been a more "up to date" version of the
>>>>>>>>>>>>>>> XML for me to
>>>>>>>>>>>> start
>>>>>>>>>>>>>> with - but there was not.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those
>>>>>>>>>>>>>>>> that appear in
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> title) for use on <https://www.rfc-editor.org/search>.
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] None added.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 3) <!-- [rfced] Section 2:  Please confirm that the
>>>>>>>>>>>>>>>> citation for
>>>>>>>>>>>>>>>> RFC 7855 ("Source Packet Routing in Networking (SPRING)
>>>>>>>>>>>>>>>> Problem
>>>>>>>>>>>>>>>> Statement and Requirements") is correct and will be
>>>>>>>>>>>>>>>> clear to readers.
>>>>>>>>>>>>>>>> We are unsure if "Source Packet Routing" and "Segment
>>>>>>>>>>>>>>>> Routing" mean
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> same thing.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] It is fine as is. Segment Routing is an instance
>>>>>>>>>>>>>>> of the more general
>>>>>>>>>>>>>> concept of "Source Packet Routing".
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> [RFC7855] discusses use cases and requirements for
>>>>>>>>>>>>>>>> Segment Routing
>>>>>>>>>>>>>>>> (SR). -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 4) <!-- [rfced] Sections 3 and subsequent:  We see that
>>>>>>>>>>>>>>>> the instances of
>>>>>>>>>>>>>>>> "TLVs 22, 23, 25, 141, 222, and 223" in RFC 8919 have
>>>>>>>>>>>>>>>> been replaced
>>>>>>>>>>>>>>>> by "TLVs Advertising Neighbor Information" in running
>>>>>>>>>>>>>>>> text in this
>>>>>>>>>>>>>>>> document.  In some places, the new text reads oddly.
>>>>>>>>>>>>>>>> Should "TLVs
>>>>>>>>>>>>>>>> Advertising Neighbor Information" be "TLVs advertising
>>>>>>>>>>>>>>>> neighbor
>>>>>>>>>>>>>>>> information", as is done in the text on
>>>>>>>>>>>>>>>> <https://www.iana.org/assignments/isis-tlv-codepoints/>?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] I have looked at the use cases - I think the text
>>>>>>>>>>>>>>> is fine as is.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> Existing advertisements used in support of RSVP-TE
>>>>>>>>>>>>>>>> include sub-TLVs
>>>>>>>>>>>>>>>> for TLVs Advertising Neighbor Information and TLVs for
>>>>>>>>>>>>>>>> Shared Risk
>>>>>>>>>>>>>>>> Link Group (SRLG) advertisement.
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> 1)  Application-Specific Link Attributes sub-TLV for
>>>>>>>>>>>>>>>> TLVs Advertising
>>>>>>>>>>>>>>>> Neighbor Information (defined in Section 4.2).
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> A new sub-TLV for TLVs Advertising Neighbor Information
>>>>>>>>>>>>>>>> is defined
>>>>>>>>>>>>>>>> that supports specification of the applications and
>>>>>>>>>>>>>>>> application-
>>>>>>>>>>>>>>>> specific attribute values.
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> When the L-flag is set in the Application Identifier Bit
>>>>>>>>>>>>>>>> Mask, all of
>>>>>>>>>>>>>>>> the applications specified in the bit mask MUST use the
>>>>>>>>>>>>>>>> legacy
>>>>>>>>>>>>>>>> advertisements for the corresponding link found in TLVs
>>>>>>>>>>>>>>>> Advertising
>>>>>>>>>>>>>>>> Neighbor Information. -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 5) <!--[rfced] Tables 1 and 5: We have changed "TE
>>>>>>>>>>>>>>>> Default Metric" to
>>>>>>>>>>>>>>>> "TE Default metric" per RFC 5305. We will ask that IANA
>>>>>>>>>>>>>>>> make this
>>>>>>>>>>>>>>>> capitalization consistent in its registies prior to
>>>>>>>>>>>>>>>> publication.
>>>>>>>>>>>>>>>> Please let us know of any objections. -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] No objection
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 6) <!-- [rfced] We see that Table 1 has a title but
>>>>>>>>>>>>>>>> Tables 2 through 7
>>>>>>>>>>>>>>>> do not.  Would you like all of the tables to have
>>>>>>>>>>>>>>>> titles?  If yes,
>>>>>>>>>>>>>>>> please provide them.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] Honestly, I think there is no need for a title for
>>>>>>>>>>>>>>> any of the tables - it is
>>>>>>>>>>>>>> the table format that is useful for presentation.
>>>>>>>>>>>>>>> So my choice would be to remove the title for Table I.
>>>>>>>>>>>>>>> If you insist, I can come up with names for the other
>>>>>>>>>>>>>>> tables, but I don’t
>>>>>>>>>>>> think
>>>>>>>>>>>>>> they add any value.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> Table 1: Sub-TLVs for TLVs Advertising
>>>>>>>>>>>>>>>> Neighbor Information
>>>>>>>>>>>>>>>> Table 2
>>>>>>>>>>>>>>>> Table 3
>>>>>>>>>>>>>>>> Table 4
>>>>>>>>>>>>>>>> Table 5
>>>>>>>>>>>>>>>> Table 6
>>>>>>>>>>>>>>>> Table 7 -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 7) <!-- [rfced] Section 4.1:  Should the section title
>>>>>>>>>>>>>>>> be "Application
>>>>>>>>>>>>>>>> Identifier Bit Masks" or "Application Identifier Bit
>>>>>>>>>>>>>>>> Mask Types"?
>>>>>>>>>>>>>>>> We ask because we see "two bit masks" in the sentence
>>>>>>>>>>>>>>>> that follows,
>>>>>>>>>>>>>>>> as well as "zero-length Application Identifier Bit
>>>>>>>>>>>>>>>> Masks" elsewhere.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] Title is fine as is.
>>>>>>>>>>>>>>> Application Identifier Bit Masks is the name of the set
>>>>>>>>>>>>>>> of fields (SABM
>>>>>>>>>>>>>> Length, UDABM Length, SABM bit mask, UDABM bit mask) which
>>>>>>>>>>>>>> are
>>>>>>>>>>>> encoded
>>>>>>>>>>>>>> in the ASLA sub-TLV.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> 4.1.  Application Identifier Bit Mask -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 8) <!-- [rfced] Sections 4.2 and 4.3:  We cannot tell
>>>>>>>>>>>>>>>> whether "SABM" in
>>>>>>>>>>>>>>>> these sentences refers to the SABM field or the SABM
>>>>>>>>>>>>>>>> Length field.
>>>>>>>>>>>>>>>> Will these sentences be clear to readers, or should
>>>>>>>>>>>>>>>> "SABM or UDABM
>>>>>>>>>>>>>>>> Length" be "SABM Length or UDABM Length"?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] It is probably clearer to say "SABM Length or
>>>>>>>>>>>>>>> UDABM length"
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> If the SABM or UDABM Length in the Application
>>>>>>>>>>>>>>>> Identifier Bit Mask is
>>>>>>>>>>>>>>>> greater than 8, the entire sub-TLV MUST be ignored.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> When SABM or UDABM Length is non-zero and the L-flag is
>>>>>>>>>>>>>>>> NOT set, all
>>>>>>>>>>>>>>>> applications specified in the bit mask MUST use the link
>>>>>>>>>>>>>>>> attribute
>>>>>>>>>>>>>>>> advertisements in the sub-TLV.
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> If the SABM or UDABM Length in the Application
>>>>>>>>>>>>>>>> Identifier Bit Mask is
>>>>>>>>>>>>>>>> greater than 8, the entire sub-TLV MUST be ignored.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> When SABM or UDABM Length is non-zero and the L-flag is
>>>>>>>>>>>>>>>> NOT set, all
>>>>>>>>>>>>>>>> applications specified in the bit mask MUST use SRLG
>>>>>>>>>>>>>>>> advertisements
>>>>>>>>>>>>>>>> in the Application-Specific SRLG TLV. -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 9) <!-- [rfced] Section 4.2:  For ease of the reader,
>>>>>>>>>>>>>>>> should "LSP" be
>>>>>>>>>>>>>>>> defined as "Label-Switched Path" per RFC 3209 or "Link
>>>>>>>>>>>>>>>> State Protocol
>>>>>>>>>>>>>>>> Data Unit" per RFC 5305?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] "Link State Protocol Data Unit"
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> In cases where conflicting values for the same
>>>>>>>>>>>>>>>> application/attribute/link are advertised, the first
>>>>>>>>>>>>>>>> advertisement
>>>>>>>>>>>>>>>> received in the lowest-numbered LSP MUST be used, and
>>>>>>>>>>>>>>>> subsequent
>>>>>>>>>>>>>>>> advertisements of the same attribute MUST be ignored.
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 10) <!-- [rfced] Section 4.3:  As it appears that "a
>>>>>>>>>>>>>>>> single TLV" refers
>>>>>>>>>>>>>>>> to the new Application-Specific SRLG TLV and not to some
>>>>>>>>>>>>>>>> other type
>>>>>>>>>>>>>>>> of TLV, we changed "a single TLV" to "this new single
>>>>>>>>>>>>>>>> TLV" here.
>>>>>>>>>>>>>>>> If this is incorrect, please provide clarifying text.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] This is fine.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original (the previous sentence is included for
>>>>>>>>>>>>>>>> context):
>>>>>>>>>>>>>>>> A new TLV is defined to advertise application-specific
>>>>>>>>>>>>>>>> SRLGs for a
>>>>>>>>>>>>>>>> given link.  Although similar in functionality to TLV
>>>>>>>>>>>>>>>> 138 [RFC5307]
>>>>>>>>>>>>>>>> and TLV 139 [RFC6119], a single TLV provides support for
>>>>>>>>>>>>>>>> IPv4, IPv6,
>>>>>>>>>>>>>>>> and unnumbered identifiers for a link.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Currently:
>>>>>>>>>>>>>>>> Although similar in functionality to TLV 138 [RFC5307]
>>>>>>>>>>>>>>>> and TLV 139 [RFC6119], this new single TLV provides
>>>>>>>>>>>>>>>> support for IPv4,
>>>>>>>>>>>>>>>> IPv6, and unnumbered identifiers for a link. -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 11) <!-- [rfced] Sections 5 and 6:  We changed
>>>>>>>>>>>>>>>> lowercased instances of
>>>>>>>>>>>>>>>> "application-specific link attribute(s)" to "ASLA(s)"
>>>>>>>>>>>>>>>> per the
>>>>>>>>>>>>>>>> expansion provided in Section 4.  Please review, and let
>>>>>>>>>>>>>>>> us know any
>>>>>>>>>>>>>>>> objections. -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] No objection
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 12) <!-- [rfced] Sections 5 and subsequent:  The
>>>>>>>>>>>>>>>> following instances of
>>>>>>>>>>>>>>>> "LFA" in these sentences read oddly.  Should they be
>>>>>>>>>>>>>>>> plural or
>>>>>>>>>>>>>>>> perhaps "LFA Policy"?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] "LFA" is correct. This refers to the application
>>>>>>>>>>>>>>> types defined in
>>>>>>>>>>>> Section
>>>>>>>>>>>>>> 4.1
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> In the case of LFA, the advertisement of application-
>>>>>>>>>>>>>>>> specific link
>>>>>>>>>>>>>>>> attributes does not indicate enablement of LFA on that
>>>>>>>>>>>>>>>> link.
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> *  The application is SR Policy or LFA, and RSVP-TE is
>>>>>>>>>>>>>>>> not deployed
>>>>>>>>>>>>>>>> anywhere in the network.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> *  The application is SR Policy or LFA, RSVP-TE is
>>>>>>>>>>>>>>>> deployed in the
>>>>>>>>>>>>>>>> network, and both the set of links on which SR Policy
>>>>>>>>>>>>>>>> and/or LFA
>>>>>>>>>>>>>>>> advertisements are required and the attribute values
>>>>>>>>>>>>>>>> used by SR
>>>>>>>>>>>>>>>> Policy and/or LFA on all such links are fully congruent
>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>> links and attribute values used by RSVP-TE.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Under the conditions defined above, implementations that
>>>>>>>>>>>>>>>> support the
>>>>>>>>>>>>>>>> extensions defined in this document have the choice of
>>>>>>>>>>>>>>>> using legacy
>>>>>>>>>>>>>>>> advertisements or application-specific advertisements in
>>>>>>>>>>>>>>>> support of
>>>>>>>>>>>>>>>> SR Policy and/or LFA.
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> Existing deployments of RSVP-TE, SR Policy, and/or LFA
>>>>>>>>>>>>>>>> utilize the
>>>>>>>>>>>>>>>> legacy advertisements listed in Section 3. -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 13) <!-- [rfced] Section 5:  Per previous text in this
>>>>>>>>>>>>>>>> document, we
>>>>>>>>>>>>>>>> changed "advertisement of link attribute advertisements"
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> "advertisement of link attributes".  If this is
>>>>>>>>>>>>>>>> incorrect, please
>>>>>>>>>>>>>>>> provide alternative text.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] This is fine.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original:
>>>>>>>>>>>>>>>> In the presence of
>>>>>>>>>>>>>>>> an application where the advertisement of link attribute
>>>>>>>>>>>>>>>> advertisements is used to infer the enablement of an
>>>>>>>>>>>>>>>> application on
>>>>>>>>>>>>>>>> that link (e.g., RSVP-TE), the absence of the
>>>>>>>>>>>>>>>> application identifier
>>>>>>>>>>>>>>>> leaves ambiguous whether that application is enabled on
>>>>>>>>>>>>>>>> such a link.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Currently:
>>>>>>>>>>>>>>>> In the presence of
>>>>>>>>>>>>>>>> an application where the advertisement of link
>>>>>>>>>>>>>>>> attributes is used to
>>>>>>>>>>>>>>>> infer the enablement of an application on that link
>>>>>>>>>>>>>>>> (e.g., RSVP-TE),
>>>>>>>>>>>>>>>> the absence of the application identifier leaves
>>>>>>>>>>>>>>>> ambiguous whether
>>>>>>>>>>>>>>>> that application is enabled on such a link. -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 14) <!-- [rfced] Section 9:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> a) We could not locate the discussion in question via
>>>>>>>>>>>>>>>> the information
>>>>>>>>>>>>>>>> in the current text.  Searching by thread on
>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/browse/lsr/> for
>>>>>>>>>>>>>>>> "Proposed Errata for RFCs 8919/8920" directed us to
>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/>, which provides an
>>>>>>>>>>>>>>>> "Enter list name or search query..." box, which did not
>>>>>>>>>>>>>>>> yield the
>>>>>>>>>>>>>>>> desired information.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] The removal of the URL was done based on feedback
>>>>>>>>>>>>>>> during IESG
>>>>>>>>>>>>>> review. IT was commented that any such URL might not be
>>>>>>>>>>>>>> valid
>>>>>>>>>>>> indefinitely.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> When I put "Proposed Errata for RFCs 8919/8920" into the
>>>>>>>>>>>>>>> search bar at
>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/lsr/ I do find
>>>>>>>>>>>>>> the relevant thread.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> However, when looking at <https://www.rfc-
>>>>>>>>>>>>>>>> editor.org/errata/eid6630>
>>>>>>>>>>>>>>>> (the erratum page for RFC 8919), we found
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>> Would pointing to this link instead of 'the thread
>>>>>>>>>>>>>>>> "Proposed Errata
>>>>>>>>>>>>>>>> for RFCs 8919/8920"' be acceptable?  If not, please
>>>>>>>>>>>>>>>> provide a URL
>>>>>>>>>>>>>>>> that can be listed as a good starting point for readers
>>>>>>>>>>>>>>>> interested in
>>>>>>>>>>>>>>>> this information.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Original (the previous sentence is included for
>>>>>>>>>>>>>>>> context):
>>>>>>>>>>>>>>>> Discussion within the LSR WG indicated that there was
>>>>>>>>>>>>>>>> confusion
>>>>>>>>>>>>>>>> regarding the use of ASLA advertisements that had a zero
>>>>>>>>>>>>>>>> length SABM/
>>>>>>>>>>>>>>>> UDABM.  The discussion can be seen by searching the LSR
>>>>>>>>>>>>>>>> WG mailing
>>>>>>>>>>>>>>>> list archives for the thread "Proposed Errata for RFCs
>>>>>>>>>>>>>>>> 8919/8920"
>>>>>>>>>>>>>>>> starting on 15 June 2021.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Possibly:
>>>>>>>>>>>>>>>> Discussion within the LSR WG indicated that there was
>>>>>>>>>>>>>>>> confusion
>>>>>>>>>>>>>>>> regarding the use of ASLA advertisements that had a
>>>>>>>>>>>>>>>> zero-length SABM/
>>>>>>>>>>>>>>>> UDABM.  The discussion can be seen on
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> b) We see that the "NEW" text for Section 4.2 was
>>>>>>>>>>>>>>>> applied per
>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/errata/eid6630> but the
>>>>>>>>>>>>>>>> "NEW" text for
>>>>>>>>>>>>>>>> Section 6.2 was not.  Is this as desired (i.e., does
>>>>>>>>>>>>>>>> "subject to the
>>>>>>>>>>>>>>>> restrictions specified in Section 4.2" in the first
>>>>>>>>>>>>>>>> paragraph of
>>>>>>>>>>>>>>>> Section 6.2 handle the erratum information adequately?)?
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 15) <!-- [rfced] We added RFC 8919 to the list of
>>>>>>>>>>>>>>>> Normative References.
>>>>>>>>>>>>>>>> Please let us know if it should be an Informative
>>>>>>>>>>>>>>>> Reference instead.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] Fine as a normative reference.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 16) <!-- [rfced] Please review the "Inclusive Language"
>>>>>>>>>>>>>>>> portion of the
>>>>>>>>>>>>>>>> online Style Guide at
>>>>>>>>>>>>>>>> <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. -->
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] No changes are needed that I can see.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 17) <!-- [rfced] The following term appears to be used
>>>>>>>>>>>>>>>> inconsistently in
>>>>>>>>>>>>>>>> this document.  Please let us know which form is
>>>>>>>>>>>>>>>> preferred.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [LES:] Please use lower case "legacy".
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Legacy sub-TLV / legacy sub-TLV (text in Section 4.2)
>>>>>>>>>>>>>>>> -->
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> RFC Editor/lb/ap
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Sep 25, 2023, at 3:10 PM, Les Ginsberg (ginsberg)
>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Folks -
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I am fine with the changes introduced with the following
>>>>>>>>>>>>>>> exceptions:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 1)Section 6.3.3
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> "while continuing to use legacy advertisements"
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Please change this to
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> "while continuing to advertise legacy advertisements"
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> The point is to indicate that both forms need to be
>>>>>>>>>>>>>>> advertised(sic).
>>>>>>>>>>>>>>> The last sentence in the paragraph clearly states what is
>>>>>>>>>>>>>>> used.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 2)Section 7.2
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> You have changed column #2 to be "Name" - but the
>>>>>>>>>>>>>>> corresponding
>>>>>>>>>>>> registry
>>>>>>>>>>>>>> uses the original term "Description".
>>>>>>>>>>>>>>> Please revert this change.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 3)Section 7.5
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> You changed the title to "IS-IS Sub-TLVs for Application-
>>>>>>>>>>>>>>> Specific SRLG TLV
>>>>>>>>>>>>>> Registry (for TLV 238)".
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> This does not match the title in the registry:
>>>>>>>>>>>>>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-
>>>>>>>>>>>>>> tlv-
>>>>>>>>>>>>>> codepoints.xhtml#tlv-238
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> "IS-IS Sub-TLVs for Application-Specific SRLG TLV"
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: [e-mail] <rfc-editor@rfc-
>>>>>>>>>>>>>>>> editor.org>
>>>>>>>>>>>>>>>> Sent: Monday, September 11, 2023 2:57 PM
>>>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>; Peter
>>>>>>>>>>>>>>>> Psenak
>>>>>>>>>>>> (ppsenak)
>>>>>>>>>>>>>>>> <[e-mail]>; [e-mail];
>>>>>>>>>>>> [e-mail];
>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail]; lsr-
>>>>>>>>>>>>>>>> [e-mail];
>>>>>>>>>>>>>>>> [e-mail]; [e-mail]; auth48archive@rfc-
>>>>>>>>>>>>>>>> editor.org
>>>>>>>>>>>>>>>> Subject: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
>>>>>>>>>>>>>>>> rfc8919bis-04> for your
>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Updated 2023/09/11
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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/rfc9479.xml
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
>>>>>>>>>>>>>>>> (side by side)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> The details of the AUTH48 status of your document are
>>>>>>>>>>>>>>>> here:
>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9479
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>> RFC9479 (draft-ietf-lsr-rfc8919bis-04)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Title            : IS-IS Application-Specific Link
>>>>>>>>>>>>>>>> Attributes
>>>>>>>>>>>>>>>> Author(s)        : L. Ginsberg, P. Psenak, S. Previdi,
>>>>>>>>>>>>>>>> W. Henderickx, J. Drake
>>>>>>>>>>>>>>>> WG Chair(s)      : Acee Lindem, Christian Hopps
>>>>>>>>>>>>>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew
>>>>>>>>>>>>>>>> Alston
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>