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

[Acee Lindem <[e-mail]>]

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]>; [e-mail]; Peter
>>>>>> Psenak (ppsenak) <[e-mail]>; [e-mail];
>>>>>> [e-mail]; [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
>>>>>> 
>>>>>> 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] <[e-mail]>
>>>>>>>>>> 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]; [e-mail];
>>>>>>>>>> [e-mail]; [e-mail]; [e-mail]
>>>>>>>>>> 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] <[e-mail]>
>>>>>>>>>> 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]; [e-mail];
>>>>>>>>>> [e-mail]; [e-mail]; [e-mail]
>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>