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

[Sabrina Tanamal via RT <[e-mail]>]

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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >