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

[Lynne Bartholomew <[e-mail]>]

Hi, Les.  So noted and forwarded to the Publisher.  Thank you!

RFC Editor/lb

> On Oct 9, 2023, at 1:12 PM, Les Ginsberg (ginsberg) <[e-mail]> wrote:
> 
> Lynne -
> 
> Great - thanx for resolving this.
> Good to go AFAIAC.
> 
>   Les
> 
>> -----Original Message-----
>> From: Lynne Bartholomew <[e-mail]>
>> Sent: Monday, October 9, 2023 1:05 PM
>> To: Les Ginsberg (ginsberg) <[e-mail]>
>> Cc: Peter Psenak (ppsenak) <[e-mail]>; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; John Scudder <[e-mail]>;
>> [e-mail]; [e-mail]; Acee Lindem
>> <[e-mail]>
>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your
>> review
>> 
>> Hi, Les.
>> 
>> After confirming that setting the "newline" parameter to "true" in the XML file
>> would not cause any issues, we updated accordingly.  The latest files are 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
>> 
>> All definition lists are now consistently formatted throughout.
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>>> On Oct 9, 2023, at 12:10 PM, Les Ginsberg (ginsberg) <[e-mail]>
>> wrote:
>>> 
>>> Lynne -
>>> It's a bit difficult for me to comment on this because I don’t know if there is
>> any negative consequence to modifying the XML file as you suggest - nor do I
>> know how long it might take to resolve the trouble ticket.
>>> AFAICT, the format differences are minor and do not affect readability
>> significantly. For example:
>>> HTML
>>> R:
>>>    Reserved. SHOULD be transmitted as 0 and MUST be ignored on receipt.
>>> UDABM Length:
>>>    Indicates the length in octets (0-8) of the User-Defined Application
>> Identifier Bit Mask. The length SHOULD be the minimum required to send all
>> bits that are set.
>>> TXT
>>> R:  Reserved.  SHOULD be transmitted as 0 and MUST be ignored on
>>>         receipt.
>>> UDABM Length:
>>>         Indicates the length in octets (0-8) of the User-Defined
>>>         Application Identifier Bit Mask.  The length SHOULD be the
>>>         minimum required to send all bits that are set.
>>> I defer to your best judgment.
>>>    Les
>>>> -----Original Message-----
>>>> From: Lynne Bartholomew <[e-mail]>
>>>> Sent: Monday, October 9, 2023 11:41 AM
>>>> To: Les Ginsberg (ginsberg) <[e-mail]>; Peter Psenak (ppsenak)
>>>> <[e-mail]>; [e-mail]; [e-mail];
>>>> [e-mail]
>>>> Cc: [e-mail]; [e-mail]; [e-mail]; John
>>>> Scudder <[e-mail]>; [e-mail]; auth48archive@rfc-
>>>> editor.org; Acee Lindem <[e-mail]>
>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for
>> your
>>>> review
>>>>> 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 <iana-
>>>> [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
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>> 
>