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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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]<mailto:[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-<mailto:[e-mail]>

> [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>

> >>>>>>> wrote:

> >>>>>>>

> >>>>>>> Hi Lynne,

> >>>>>>>

> >>>>>>>> On Oct 4, 2023, at 12:27, Lynne Bartholomew

> >>>>>>>> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:

> >>>>>>>>>>>

> >>>>>>>>>>> I also approve

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>> On Sep 30, 2023, at 2:47 AM, Peter Psenak

> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>

> >>>>>>>>>>>>> Sent: Thursday, September 28, 2023 1:49 PM

> >>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>

> >>>>>>>>>>>>> Cc: Acee Lindem <[e-mail]<mailto:[e-mail]>>; rfc-editor@rfc-

> >>>>>>>>>>>>> editor.org; Peter

> >>>>>>>>>>>>> Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>;

> [e-mail]<mailto:[e-mail]>;

> >>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; lsr-

> >>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; lsr-

> >>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>

> >>>>>>>>>>>>>>> Sent: Wednesday, September 27, 2023 1:42 PM

> >>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Acee

> >>>>>>>>>>>>>>> Lindem

> >>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>

> >>>>>>>>>>>>>>> Cc: [e-mail]<mailto:[e-mail]>; Peter Psenak (ppsenak)

> >>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>;

> >>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> >>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; lsr-

> >>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> >>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>;

> >>>>>>>>>>>>>>> [e-mail]<mailto:[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-<https://www.rfc-editor.org/authors/rfc9479-auth48diff.html>

> auth48diff.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]<mailto: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]<mailto:[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]<mailto: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]<mailto: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]<mailto:ginsberg=[e-mail]>> wrote:

> >>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>> Folks -

> >>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>> Please find my responses to your questions inline below.

> >>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>>> -----Original Message-----

> >>>>>>>>>>>>>>>>> From: [e-mail]<mailto:[e-mail]> <rfc-editor@rfc-

> >>>>>>>>>>>>>>>>> editor.org>

> >>>>>>>>>>>>>>>>> Sent: Monday, September 11, 2023 2:59 PM

> >>>>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Peter

> >>>>>>>>>>>>>>>>> Psenak

> >>>>>>>>>>>>> (ppsenak)

> >>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> >>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>;

> >>>>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>

> >>>>>>>>>>>>>>>>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; lsr-

> >>>>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>;

> >>>>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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-<https://www.iana.org/assignments/isis-tlv-codepoints/>

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

> >>>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>

> >>>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>>

> >>>>>>>>>

> >>>>>>>>>

> >>>>>>>>

> >>>>>>>

> >>>>>>

> >>>>>

> >>>>

> >>

> >