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

[Lynne Bartholomew <[e-mail]>]

Dear authors,

This trouble ticket is still open and affects some of the lists in this document:  <https://github.com/ietf-tools/xml2rfc/issues/1045>.

Please let us know whether (1) we may update the XML file to set the "newline" parameter to "true" for these lists, so that the displays are consistent or (2) you prefer that we wait for this issue to be fixed before we publish this document.

Thank you!

RFC Editor/lb

> On Oct 6, 2023, at 3:03 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> 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
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>