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

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

Lynne -

Great - thanx for resolving this.
Good to go AFAIAC.

   Les

> -----Original Message-----
> From: Lynne Bartholomew <[e-mail]>
> Sent: Monday, October 9, 2023 1:05 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Peter Psenak (ppsenak) <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; John Scudder <[e-mail]>;
> [e-mail]; [e-mail]; Acee Lindem
> <[e-mail]>
> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your
> review
> 
> Hi, Les.
> 
> After confirming that setting the "newline" parameter to "true" in the XML file
> would not cause any issues, we updated accordingly.  The latest files are here
> (please refresh your browser):
> 
>    https://www.rfc-editor.org/authors/rfc9479.txt
>    https://www.rfc-editor.org/authors/rfc9479.pdf
>    https://www.rfc-editor.org/authors/rfc9479.html
>    https://www.rfc-editor.org/authors/rfc9479.xml
>    https://www.rfc-editor.org/authors/rfc9479-diff.html
>    https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
>    https://www.rfc-editor.org/authors/rfc9479-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc9479-lastdiff.html
>    https://www.rfc-editor.org/authors/rfc9479-lastrfcdiff.html
> 
>    https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
>    https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html
> 
> All definition lists are now consistently formatted throughout.
> 
> Thank you!
> 
> RFC Editor/lb
> 
> > On Oct 9, 2023, at 12:10 PM, Les Ginsberg (ginsberg) <[e-mail]>
> wrote:
> >
> > Lynne -
> >  It's a bit difficult for me to comment on this because I don’t know if there is
> any negative consequence to modifying the XML file as you suggest - nor do I
> know how long it might take to resolve the trouble ticket.
> >  AFAICT, the format differences are minor and do not affect readability
> significantly. For example:
> >  HTML
> >  R:
> >     Reserved. SHOULD be transmitted as 0 and MUST be ignored on receipt.
> >  UDABM Length:
> >     Indicates the length in octets (0-8) of the User-Defined Application
> Identifier Bit Mask. The length SHOULD be the minimum required to send all
> bits that are set.
> >  TXT
> >  R:  Reserved.  SHOULD be transmitted as 0 and MUST be ignored on
> >          receipt.
> >  UDABM Length:
> >          Indicates the length in octets (0-8) of the User-Defined
> >          Application Identifier Bit Mask.  The length SHOULD be the
> >          minimum required to send all bits that are set.
> >  I defer to your best judgment.
> >     Les
> >  > -----Original Message-----
> > > From: Lynne Bartholomew <[e-mail]>
> > > Sent: Monday, October 9, 2023 11:41 AM
> > > To: Les Ginsberg (ginsberg) <[e-mail]>; Peter Psenak (ppsenak)
> > > <[e-mail]>; [e-mail]; [e-mail];
> > > [e-mail]
> > > Cc: [e-mail]; [e-mail]; [e-mail]; John
> > > Scudder <[e-mail]>; [e-mail]; auth48archive@rfc-
> > > editor.org; Acee Lindem <[e-mail]>
> > > Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for
> your
> > > review
> > > > Dear authors,
> > > > This trouble ticket is still open and affects some of the lists in this
> document:
> > > <https://github.com/ietf-tools/xml2rfc/issues/1045>.
> > > > Please let us know whether (1) we may update the XML file to set the
> > > "newline" parameter to "true" for these lists, so that the displays are
> > > consistent or (2) you prefer that we wait for this issue to be fixed before we
> > > publish this document.
> > > > Thank you!
> > > > RFC Editor/lb
> > > > > On Oct 6, 2023, at 3:03 PM, Lynne Bartholomew
> > > <[e-mail]> wrote:
> > > >
> > > > Hi, Sabrina.  Looks great!  Thank you!
> > > >
> > > > RFC Editor/lb
> > > >
> > > >> On Oct 6, 2023, at 2:58 PM, Sabrina Tanamal via RT <iana-
> > > [e-mail]> wrote:
> > > >>
> > > >> Hi Lynne,
> > > >>
> > > >> These changes are complete:
> > > >>
> > > >> https://www.iana.org/assignments/isis-tlv-codepoints
> > > >> https://www.iana.org/assignments/igp-parameters
> > > >>
> > > >> Thanks,
> > > >> Sabrina
> > > >>
> > > >> On Thu Oct 05 17:04:59 2023, [e-mail] wrote:
> > > >>> Dear IANA,
> > > >>>
> > > >>> We are preparing this document for publication.  Please make the
> > > >>> following updates per this document (https://www.rfc-
> > > >>> editor.org/authors/rfc9479.txt):
> > > >>>
> > > >>> 1) Please make the following updates on
> > > >>> <https://www.iana.org/assignments/isis-tlv-codepoints/>:
> > > >>>
> > > >>> OLD:
> > > >>> 18 TE Default Metric [RFC5305]
> > > >>>
> > > >>> NEW (in the "IS-IS Sub-Sub-TLV Codepoints for Application-Specific
> > > >>> Link Attributes" registry -- per RFC 5305):
> > > >>> 18 TE Default metric [RFC5305]
> > > >>>
> > > >>> OLD:
> > > >>> Description
> > > >>>   This registry defines sub-TLVs for Application Specific SRLG TLV
> > > >>> (238).
> > > >>>
> > > >>> NEW (in the "IS-IS Sub-TLVs for Application-Specific SRLG TLV"
> > > >>> registry -- add a hyphen to "Application Specific"):
> > > >>> Description
> > > >>>   This registry defines sub-TLVs for the Application-Specific SRLG
> > > >>> TLV (TLV 238).
> > > >>>
> > > >>> = = = = =
> > > >>>
> > > >>> 2) Per Table 6 in this document, please add a hyphen to "Loop Free" in
> > > >>> "Loop Free Alternate (F-bit)" in the "Link Attribute Application
> > > >>> Identifiers" registry on <https://www.iana.org/assignments/igp-
> > > >>> parameters/>:
> > > >>>
> > > >>> OLD:
> > > >>> 2    Loop Free Alternate (F-bit)    [RFC-ietf-lsr-rfc8919bis-04]
> > > >>>
> > > >>> NEW:
> > > >>> 2    Loop-Free Alternate (F-bit)    [RFC-ietf-lsr-rfc8919bis-04]
> > > >>>
> > > >>>
> > > >>> Thank you!
> > > >>>
> > > >>> RFC Editor/lb
> > > >>>
> > > >>>
> > > >>>> On Oct 4, 2023, at 1:41 PM, Lynne Bartholomew
> > > <[e-mail]>
> > > >>>> wrote:
> > > >>>>
> > > >>>> Hi, Acee.  So noted on <https://www.rfc-editor.org/auth48/rfc9479>.
> > > >>>> Thank you!
> > > >>>>
> > > >>>> RFC Editor/lb
> > > >>>>
> > > >>>>> On Oct 4, 2023, at 1:13 PM, Acee Lindem <[e-mail]>
> > > wrote:
> > > >>>>>
> > > >>>>> I forgot to mention - this version looks good to me.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> Acee
> > > >>>>>
> > > >>>>>> On Oct 4, 2023, at 12:54 PM, Lynne Bartholomew
> > > >>>>>> <[e-mail]> wrote:
> > > >>>>>>
> > > >>>>>> Hi, Acee.  I'll let the editor of RFC 9492 know.  Thank you!
> > > >>>>>>
> > > >>>>>> RFC Editor/lb
> > > >>>>>>
> > > >>>>>>> On Oct 4, 2023, at 9:47 AM, Acee Lindem <[e-mail]>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> Hi Lynne,
> > > >>>>>>>
> > > >>>>>>>> On Oct 4, 2023, at 12:27, Lynne Bartholomew
> > > >>>>>>>> <[e-mail]> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Hi, Acee.  No worries, and thank you for aligning the wording in
> > > >>>>>>>> this document with RFC 9492!
> > > >>>>>>>>
> > > >>>>>>>> Because we changed "introducing new backwards-compatibility
> > > >>>>>>>> issues" to "introducing backwards-compatibility issues" in this
> > > >>>>>>>> document, please confirm that "introducing new backwards-
> > > >>>>>>>> compatibility issues" in RFC 9492 is as desired.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> I’d remove it from RFC 9492 as well. It is correct both ways but
> > > >>>>>>> “introducing” implies “new” so it is redundant.
> > > >>>>>>>
> > > >>>>>>> Thanks,
> > > >>>>>>> Acee
> > > >>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> The latest files for this document are posted here (please
> > > >>>>>>>> refresh your browser):
> > > >>>>>>>>
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479-auth48diff.html
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastdiff.html
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastrfcdiff.html
> > > >>>>>>>>
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
> > > >>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html
> > > >>>>>>>>
> > > >>>>>>>> Thanks again!
> > > >>>>>>>>
> > > >>>>>>>> RFC Editor/lb
> > > >>>>>>>>
> > > >>>>>>>>> On Oct 3, 2023, at 10:35 AM, Acee Lindem
> <[e-mail]>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> Thanks Lynne - apologies but I neglected to remove some of the
> > > >>>>>>>>> instances of “new” which are no longer new.
> > > >>>>>>>>>
> > > >>>>>>>>> *** rfc9479.txt.orig Tue Oct  3 13:31:44 2023
> > > >>>>>>>>> --- rfc9479.txt Tue Oct  3 13:33:15 2023
> > > >>>>>>>>> ***************
> > > >>>>>>>>> *** 189,195 ****
> > > >>>>>>>>> attributes may grow in the future, an additional requirement is
> > > >>>>>>>>> that
> > > >>>>>>>>> the extensions defined allow the association of additional
> > > >>>>>>>>> applications to link attributes without altering the format of
> > > >>>>>>>>> the
> > > >>>>>>>>> !    advertisements or introducing new backwards-compatibility
> > > >>>>>>>>> issues.
> > > >>>>>>>>>
> > > >>>>>>>>> Finally, there may still be many cases where a single attribute
> > > >>>>>>>>> value
> > > >>>>>>>>> can be shared among multiple applications, so the solution
> must
> > > >>>>>>>>> --- 189,195 ----
> > > >>>>>>>>> attributes may grow in the future, an additional requirement is
> > > >>>>>>>>> that
> > > >>>>>>>>> the extensions defined allow the association of additional
> > > >>>>>>>>> applications to link attributes without altering the format of
> > > >>>>>>>>> the
> > > >>>>>>>>> !    advertisements or introducing backwards-compatibility
> > > >>>>>>>>> issues.
> > > >>>>>>>>>
> > > >>>>>>>>> Finally, there may still be many cases where a single attribute
> > > >>>>>>>>> value
> > > >>>>>>>>> can be shared among multiple applications, so the solution
> must
> > > >>>>>>>>> ***************
> > > >>>>>>>>> *** 254,260 ****
> > > >>>>>>>>>
> > > >>>>>>>>> 4.  Advertising Application-Specific Link Attributes
> > > >>>>>>>>>
> > > >>>>>>>>> !    Two new codepoints are defined to support Application-
> > > >>>>>>>>> Specific Link
> > > >>>>>>>>> Attribute (ASLA) advertisements:
> > > >>>>>>>>>
> > > >>>>>>>>> 1.  Application-Specific Link Attributes sub-TLV for TLVs
> > > >>>>>>>>> Advertising
> > > >>>>>>>>> --- 254,260 ----
> > > >>>>>>>>>
> > > >>>>>>>>> 4.  Advertising Application-Specific Link Attributes
> > > >>>>>>>>>
> > > >>>>>>>>> !    Two codepoints are defined to support Application-Specific
> > > >>>>>>>>> Link
> > > >>>>>>>>> Attribute (ASLA) advertisements:
> > > >>>>>>>>>
> > > >>>>>>>>> 1.  Application-Specific Link Attributes sub-TLV for TLVs
> > > >>>>>>>>> Advertising
> > > >>>>>>>>> ***************
> > > >>>>>>>>> *** 272,285 ****
> > > >>>>>>>>> not subject to standardization and are outside the scope of this
> > > >>>>>>>>> document.
> > > >>>>>>>>>
> > > >>>>>>>>> !    The following sections define the format of these new
> > > >>>>>>>>> advertisements.
> > > >>>>>>>>>
> > > >>>>>>>>> 4.1.  Application Identifier Bit Mask
> > > >>>>>>>>>
> > > >>>>>>>>> Identification of the set of applications associated with link
> > > >>>>>>>>> attribute advertisements utilizes two bit masks.  One bit mask
> > > >>>>>>>>> is for
> > > >>>>>>>>> standard applications where the definition of each bit is
> > > >>>>>>>>> defined in
> > > >>>>>>>>> !    a new IANA-controlled registry (see Section 7.4).  A second
> > > >>>>>>>>> bit mask
> > > >>>>>>>>> is for non-standard UDAs.
> > > >>>>>>>>>
> > > >>>>>>>>> The encoding defined below is used by both the Application-
> > > >>>>>>>>> Specific
> > > >>>>>>>>> --- 272,285 ----
> > > >>>>>>>>> not subject to standardization and are outside the scope of this
> > > >>>>>>>>> document.
> > > >>>>>>>>>
> > > >>>>>>>>> !    The following sections define the format of these
> > > >>>>>>>>> advertisements.
> > > >>>>>>>>>
> > > >>>>>>>>> 4.1.  Application Identifier Bit Mask
> > > >>>>>>>>>
> > > >>>>>>>>> Identification of the set of applications associated with link
> > > >>>>>>>>> attribute advertisements utilizes two bit masks.  One bit mask
> > > >>>>>>>>> is for
> > > >>>>>>>>> standard applications where the definition of each bit is
> > > >>>>>>>>> defined in
> > > >>>>>>>>> !    an IANA-controlled registry (see Section 7.4).  A second
> > > >>>>>>>>> bit mask
> > > >>>>>>>>> is for non-standard UDAs.
> > > >>>>>>>>>
> > > >>>>>>>>> The encoding defined below is used by both the Application-
> > > >>>>>>>>> Specific
> > > >>>>>>>>>
> > > >>>>>>>>> Thanks,
> > > >>>>>>>>> Acee
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> On Oct 3, 2023, at 1:13 PM, Lynne Bartholomew
> > > >>>>>>>>>> <[e-mail]> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> Hi, Acee, Peter, Wim, and Stefano.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Acee, we have updated this document per your notes below.
> > > >>>>>>>>>>
> > > >>>>>>>>>> The latest files are posted here (please refresh your browser):
> > > >>>>>>>>>>
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-auth48diff.html
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastdiff.html
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-lastrfcdiff.html
> > > >>>>>>>>>>
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
> > > >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html
> > > >>>>>>>>>>
> > > >>>>>>>>>> Peter, Wim, and Stefano, we have noted your approvals on the
> > > >>>>>>>>>> AUTH48 status page:
> > > >>>>>>>>>>
> > > >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9479
> > > >>>>>>>>>>
> > > >>>>>>>>>> We now have all author approvals for this document.  We will
> > > >>>>>>>>>> ask IANA to (1) confirm that all references to RFC 8919 in
> > > >>>>>>>>>> their registries now point to this document and (2) make
> > > >>>>>>>>>> additional updates, as applicable, to match this document.
> > > >>>>>>>>>> After those changes are complete, we will prepare this
> document
> > > >>>>>>>>>> for publication.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Thank you!
> > > >>>>>>>>>>
> > > >>>>>>>>>> RFC Editor/lb
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Oct 1, 2023, at 2:25 AM, Stefano Previdi
> > > >>>>>>>>>>> <[e-mail]> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I also approve the publication.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks.
> > > >>>>>>>>>>> s.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Sep 30, 2023, at 9:57 PM, Wim Henderickx (Nokia)
> > > >>>>>>>>>>> <[e-mail]> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I also approve
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Sep 30, 2023, at 2:47 AM, Peter Psenak
> > > <[e-mail]>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Hi Lynne,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> you have my approval as well.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> thanks,
> > > >>>>>>>>>>> Peter
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Sep 29, 2023, at 1:32 PM, Acee Lindem
> > > <[e-mail]>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Hi Les, Lynne,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Here are the edits analogous to those I request for RFC 9492.
> > > >>>>>>>>>>> Mostly, removing “new” where it is redundant.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> *** rfc9479.txt.orig Fri Sep 29 16:29:06 2023
> > > >>>>>>>>>>> --- rfc9479.txt Fri Sep 29 16:26:23 2023
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 27,33 ****
> > > >>>>>>>>>>> attributes, the current advertisements do not support
> > > >>>>>>>>>>> application-
> > > >>>>>>>>>>> specific values for a given attribute, nor do they support an
> > > >>>>>>>>>>> indication of which applications are using the advertised
> > > >>>>>>>>>>> value for a
> > > >>>>>>>>>>> !    given link.  This document introduces new link attribute
> > > >>>>>>>>>>> advertisements that address both of these shortcomings.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> This document obsoletes RFC 8919.
> > > >>>>>>>>>>> --- 27,33 ----
> > > >>>>>>>>>>> attributes, the current advertisements do not support
> > > >>>>>>>>>>> application-
> > > >>>>>>>>>>> specific values for a given attribute, nor do they support an
> > > >>>>>>>>>>> indication of which applications are using the advertised
> > > >>>>>>>>>>> value for a
> > > >>>>>>>>>>> !    given link.  This document introduces link attribute
> > > >>>>>>>>>>> advertisements that address both of these shortcomings.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> This document obsoletes RFC 8919.
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 137,143 ****
> > > >>>>>>>>>>> advertised for that link, it assumes that RSVP-TE is enabled
> > > >>>>>>>>>>> on that
> > > >>>>>>>>>>> link, even though it is not.  If such an RSVP-TE head-end
> > > >>>>>>>>>>> router
> > > >>>>>>>>>>> tries to set up an RSVP-TE path via that link, it will result
> > > >>>>>>>>>>> in a
> > > >>>>>>>>>>> !    path setup failure.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> An additional issue arises in cases where both applications
> > > >>>>>>>>>>> are
> > > >>>>>>>>>>> supported on a link but the link attribute values associated
> > > >>>>>>>>>>> with
> > > >>>>>>>>>>> --- 137,143 ----
> > > >>>>>>>>>>> advertised for that link, it assumes that RSVP-TE is enabled
> > > >>>>>>>>>>> on that
> > > >>>>>>>>>>> link, even though it is not.  If such an RSVP-TE head-end
> > > >>>>>>>>>>> router
> > > >>>>>>>>>>> tries to set up an RSVP-TE path via that link, it will result
> > > >>>>>>>>>>> in a
> > > >>>>>>>>>>> !    setup failure for the path.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> An additional issue arises in cases where both applications
> > > >>>>>>>>>>> are
> > > >>>>>>>>>>> supported on a link but the link attribute values associated
> > > >>>>>>>>>>> with
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 262,268 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 2.  Application-Specific SRLG TLV (defined in Section 4.3).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    To support these new advertisements, an application
> > > >>>>>>>>>>> identifier bit
> > > >>>>>>>>>>> mask is defined to identify the application(s) associated with
> > > >>>>>>>>>>> a
> > > >>>>>>>>>>> given advertisement (defined in Section 4.1).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> --- 262,268 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 2.  Application-Specific SRLG TLV (defined in Section 4.3).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    To support these advertisements, an application
> > > >>>>>>>>>>> identifier bit
> > > >>>>>>>>>>> mask is defined to identify the application(s) associated with
> > > >>>>>>>>>>> a
> > > >>>>>>>>>>> given advertisement (defined in Section 4.1).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 381,387 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 4.2.  Application-Specific Link Attributes Sub-TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    A new sub-TLV for TLVs Advertising Neighbor Information
> > > >>>>>>>>>>> is defined
> > > >>>>>>>>>>> that supports specification of the applications and
> > > >>>>>>>>>>> application-
> > > >>>>>>>>>>> specific attribute values.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> --- 381,387 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 4.2.  Application-Specific Link Attributes Sub-TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    A sub-TLV for TLVs Advertising Neighbor Information is
> > > >>>>>>>>>>> defined
> > > >>>>>>>>>>> that supports specification of the applications and
> > > >>>>>>>>>>> application-
> > > >>>>>>>>>>> specific attribute values.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 439,445 ****
> > > >>>>>>>>>>> Application Identifier Bit set are present for a given link.
> > > >>>>>>>>>>> Otherwise, such link attribute advertisements MUST NOT be
> > > >>>>>>>>>>> used.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a new registry of sub-sub-TLVs to define
> > > >>>>>>>>>>> the link
> > > >>>>>>>>>>> attribute sub-sub-TLV codepoints (see Section 7.3).  This
> > > >>>>>>>>>>> document
> > > >>>>>>>>>>> defines a sub-sub-TLV for each of the existing sub-TLVs listed
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>> Section 3.1, except as noted below.  The format of the sub-
> > > >>>>>>>>>>> sub-TLVs
> > > >>>>>>>>>>> --- 439,445 ----
> > > >>>>>>>>>>> Application Identifier Bit set are present for a given link.
> > > >>>>>>>>>>> Otherwise, such link attribute advertisements MUST NOT be
> > > >>>>>>>>>>> used.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a registry of sub-sub-TLVs to define the
> > > >>>>>>>>>>> link
> > > >>>>>>>>>>> attribute sub-sub-TLV codepoints (see Section 7.3).  This
> > > >>>>>>>>>>> document
> > > >>>>>>>>>>> defines a sub-sub-TLV for each of the existing sub-TLVs listed
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>> Section 3.1, except as noted below.  The format of the sub-
> > > >>>>>>>>>>> sub-TLVs
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 464,470 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> It is also possible to advertise a single advertisement with a
> > > >>>>>>>>>>> zero-
> > > >>>>>>>>>>> length SABM and UDABM so long as the constraints
> discussed in
> > > >>>>>>>>>>> !    Sections 4.2 and 6.2 are acceptable.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> If different values for maximum link bandwidth for a given
> > > >>>>>>>>>>> link are
> > > >>>>>>>>>>> advertised, all values MUST be ignored.
> > > >>>>>>>>>>> --- 464,470 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> It is also possible to advertise a single advertisement with a
> > > >>>>>>>>>>> zero-
> > > >>>>>>>>>>> length SABM and UDABM so long as the constraints
> discussed in
> > > >>>>>>>>>>> !    Sections 4.2 and 6.2 are satisfied.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> If different values for maximum link bandwidth for a given
> > > >>>>>>>>>>> link are
> > > >>>>>>>>>>> advertised, all values MUST be ignored.
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 497,505 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 4.3.  Application-Specific SRLG TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    A new TLV is defined to advertise application-specific
> > > >>>>>>>>>>> SRLGs for a
> > > >>>>>>>>>>> given link.  Although similar in functionality to TLV 138
> > > >>>>>>>>>>> [RFC5307]
> > > >>>>>>>>>>> !    and TLV 139 [RFC6119], this new single TLV provides
> > > >>>>>>>>>>> support for IPv4,
> > > >>>>>>>>>>> IPv6, and unnumbered identifiers for a link.  Unlike TLVs 138
> > > >>>>>>>>>>> and
> > > >>>>>>>>>>> 139, it utilizes sub-TLVs to encode the link identifiers in
> > > >>>>>>>>>>> order to
> > > >>>>>>>>>>> provide the flexible formatting required to support multiple
> > > >>>>>>>>>>> link
> > > >>>>>>>>>>> --- 497,505 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 4.3.  Application-Specific SRLG TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    A TLV is defined to advertise application-specific SRLGs
> > > >>>>>>>>>>> for a
> > > >>>>>>>>>>> given link.  Although similar in functionality to TLV 138
> > > >>>>>>>>>>> [RFC5307]
> > > >>>>>>>>>>> !    and TLV 139 [RFC6119], this single TLV provides support
> > > >>>>>>>>>>> for IPv4,
> > > >>>>>>>>>>> IPv6, and unnumbered identifiers for a link.  Unlike TLVs 138
> > > >>>>>>>>>>> and
> > > >>>>>>>>>>> 139, it utilizes sub-TLVs to encode the link identifiers in
> > > >>>>>>>>>>> order to
> > > >>>>>>>>>>> provide the flexible formatting required to support multiple
> > > >>>>>>>>>>> link
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 758,764 ****
> > > >>>>>>>>>>> This section lists the protocol codepoint changes introduced
> > > >>>>>>>>>>> by this
> > > >>>>>>>>>>> document and the related IANA updates.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    For the new registries defined under the "IS-IS TLV
> > > >>>>>>>>>>> Codepoints" group
> > > >>>>>>>>>>> of registries with a registration procedure of "Expert Review"
> > > >>>>>>>>>>> (see
> > > >>>>>>>>>>> Sections 7.3 and 7.5), guidance for designated experts can be
> > > >>>>>>>>>>> found
> > > >>>>>>>>>>> in [RFC7370].
> > > >>>>>>>>>>> --- 758,764 ----
> > > >>>>>>>>>>> This section lists the protocol codepoint changes introduced
> > > >>>>>>>>>>> by this
> > > >>>>>>>>>>> document and the related IANA updates.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    For the registries defined under the "IS-IS TLV
> > > >>>>>>>>>>> Codepoints" group
> > > >>>>>>>>>>> of registries with a registration procedure of "Expert Review"
> > > >>>>>>>>>>> (see
> > > >>>>>>>>>>> Sections 7.3 and 7.5), guidance for designated experts can be
> > > >>>>>>>>>>> found
> > > >>>>>>>>>>> in [RFC7370].
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 768,774 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.1.  Application-Specific Link Attributes Sub-TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has registered the new sub-TLV defined in Section
> > > >>>>>>>>>>> 4.2 in the
> > > >>>>>>>>>>> "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information"
> > > >>>>>>>>>>> registry.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > >
> +======+======================+====+====+======+=====+=====+=====+
> > > >>>>>>>>>>> --- 768,774 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.1.  Application-Specific Link Attributes Sub-TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has registered the sub-TLV defined in Section 4.2 in
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>> "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information"
> > > >>>>>>>>>>> registry.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > >
> +======+======================+====+====+======+=====+=====+=====+
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 782,788 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.2.  Application-Specific SRLG TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has registered the new TLV defined in Section 4.3 in
> > > >>>>>>>>>>> the "IS-IS
> > > >>>>>>>>>>> Top-Level TLV Codepoints" registry.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > +=======+===========================+=====+=====+=====+=======+
> > > >>>>>>>>>>> --- 782,788 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.2.  Application-Specific SRLG TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has registered the TLV defined in Section 4.3 in the
> > > >>>>>>>>>>> "IS-IS
> > > >>>>>>>>>>> Top-Level TLV Codepoints" registry.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > +=======+===========================+=====+=====+=====+=======+
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 796,802 ****
> > > >>>>>>>>>>> 7.3.  IS-IS Sub-Sub-TLV Codepoints for Application-Specific
> > > >>>>>>>>>>> Link
> > > >>>>>>>>>>> Attributes Registry
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a new registry titled "IS-IS Sub-Sub-TLV
> > > >>>>>>>>>>> Codepoints
> > > >>>>>>>>>>> for Application-Specific Link Attributes" under the "IS-IS TLV
> > > >>>>>>>>>>> Codepoints" registry to control the assignment of sub-sub-
> TLV
> > > >>>>>>>>>>> codepoints for the Application-Specific Link Attributes sub-
> > > >>>>>>>>>>> TLV
> > > >>>>>>>>>>> --- 796,802 ----
> > > >>>>>>>>>>> 7.3.  IS-IS Sub-Sub-TLV Codepoints for Application-Specific
> > > >>>>>>>>>>> Link
> > > >>>>>>>>>>> Attributes Registry
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a registry titled "IS-IS Sub-Sub-TLV
> > > >>>>>>>>>>> Codepoints
> > > >>>>>>>>>>> for Application-Specific Link Attributes" under the "IS-IS TLV
> > > >>>>>>>>>>> Codepoints" registry to control the assignment of sub-sub-
> TLV
> > > >>>>>>>>>>> codepoints for the Application-Specific Link Attributes sub-
> > > >>>>>>>>>>> TLV
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 863,869 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.4.  Link Attribute Application Identifiers Registry
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a new registry titled "Link Attribute
> > > >>>>>>>>>>> Application
> > > >>>>>>>>>>> Identifiers" within the "Interior Gateway Protocol (IGP)
> > > >>>>>>>>>>> Parameters"
> > > >>>>>>>>>>> group of registries to control the assignment of Application
> > > >>>>>>>>>>> Identifier Bits.  The registration policy for this registry is
> > > >>>>>>>>>>> --- 863,869 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.4.  Link Attribute Application Identifiers Registry
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a registry titled "Link Attribute
> > > >>>>>>>>>>> Application
> > > >>>>>>>>>>> Identifiers" within the "Interior Gateway Protocol (IGP)
> > > >>>>>>>>>>> Parameters"
> > > >>>>>>>>>>> group of registries to control the assignment of Application
> > > >>>>>>>>>>> Identifier Bits.  The registration policy for this registry is
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 889,895 ****
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.5.  IS-IS Sub-TLVs for Application-Specific SRLG TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a new registry titled "IS-IS Sub-TLVs
> > > >>>>>>>>>>> for
> > > >>>>>>>>>>> Application-Specific SRLG TLV" under the "IS-IS TLV
> > > >>>>>>>>>>> Codepoints"
> > > >>>>>>>>>>> registry to control the assignment of sub-TLV types for the
> > > >>>>>>>>>>> Application-Specific SRLG TLV (TLV 238).  The registration
> > > >>>>>>>>>>> procedure
> > > >>>>>>>>>>> --- 889,895 ----
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 7.5.  IS-IS Sub-TLVs for Application-Specific SRLG TLV
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    IANA has created a registry titled "IS-IS Sub-TLVs for
> > > >>>>>>>>>>> Application-Specific SRLG TLV" under the "IS-IS TLV
> > > >>>>>>>>>>> Codepoints"
> > > >>>>>>>>>>> registry to control the assignment of sub-TLV types for the
> > > >>>>>>>>>>> Application-Specific SRLG TLV (TLV 238).  The registration
> > > >>>>>>>>>>> procedure
> > > >>>>>>>>>>> ***************
> > > >>>>>>>>>>> *** 938,944 ****
> > > >>>>>>>>>>> deployments, the stronger authentication mechanisms
> defined
> > > in
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>> aforementioned documents SHOULD be used.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    This document defines a new way to advertise link
> > > >>>>>>>>>>> attributes.
> > > >>>>>>>>>>> Tampering with the information defined in this document
> may
> > > >>>>>>>>>>> have an
> > > >>>>>>>>>>> effect on applications using it, including impacting TE as
> > > >>>>>>>>>>> discussed
> > > >>>>>>>>>>> in [RFC8570].  As the advertisements defined in this
> document
> > > >>>>>>>>>>> limit
> > > >>>>>>>>>>> --- 938,944 ----
> > > >>>>>>>>>>> deployments, the stronger authentication mechanisms
> defined
> > > in
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>> aforementioned documents SHOULD be used.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> !    This document defines an improved way to advertise link
> > > >>>>>>>>>>> attributes.
> > > >>>>>>>>>>> Tampering with the information defined in this document
> may
> > > >>>>>>>>>>> have an
> > > >>>>>>>>>>> effect on applications using it, including impacting TE as
> > > >>>>>>>>>>> discussed
> > > >>>>>>>>>>> in [RFC8570].  As the advertisements defined in this
> document
> > > >>>>>>>>>>> limit
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks,
> > > >>>>>>>>>>> Acee
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Sep 28, 2023, at 6:15 PM, Les Ginsberg (ginsberg)
> > > >>>>>>>>>>>> <[e-mail]> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Lynne -
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thanx for the clarification.
> > > >>>>>>>>>>>> I still prefer no table names - I can live with the format
> > > >>>>>>>>>>>> limitations.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Les
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> -----Original Message-----
> > > >>>>>>>>>>>>> From: Lynne Bartholomew <[e-mail]>
> > > >>>>>>>>>>>>> Sent: Thursday, September 28, 2023 1:49 PM
> > > >>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>
> > > >>>>>>>>>>>>> Cc: Acee Lindem <[e-mail]>; rfc-editor@rfc-
> > > >>>>>>>>>>>>> editor.org; Peter
> > > >>>>>>>>>>>>> Psenak (ppsenak) <[e-mail]>;
> > > [e-mail];
> > > >>>>>>>>>>>>> [e-mail]; [e-mail]; lsr-
> > > >>>>>>>>>>>>> [e-mail]; lsr-
> > > >>>>>>>>>>>>> [e-mail]; [e-mail]; [e-mail];
> > > >>>>>>>>>>>>> auth48archive@rfc-
> > > >>>>>>>>>>>>> editor.org
> > > >>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
> > > >>>>>>>>>>>>> rfc8919bis-04> for your
> > > >>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Hi, Les.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thank you for the clarification re. question 14)b) and the
> > > >>>>>>>>>>>>> erratum text.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> As for the placement of the "Table X" lines in the PDF and
> > > >>>>>>>>>>>>> HTML files, this is a
> > > >>>>>>>>>>>>> feature of xml2rfc v3, and we're not able to center the
> > > >>>>>>>>>>>>> "Table X" lines in PDF or
> > > >>>>>>>>>>>>> HTML.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> We know that the topic of table titles in this document was
> > > >>>>>>>>>>>>> covered earlier --
> > > >>>>>>>>>>>>> not to use any for this document -- but if the tables had
> > > >>>>>>>>>>>>> titles, this effect would
> > > >>>>>>>>>>>>> not be so jarring in the PDF and HTML files.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Please let us know what you think; we'll wait to hear from
> > > >>>>>>>>>>>>> you again before
> > > >>>>>>>>>>>>> noting your approval.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks for your patience!
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> RFC Editor/lb
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Sep 27, 2023, at 3:10 PM, Les Ginsberg (ginsberg)
> > > >>>>>>>>>>>>> <[e-mail]> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Lynne -
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I have checked all of the additional changes - they have
> > > >>>>>>>>>>>>>> all been completed to
> > > >>>>>>>>>>>>> my satisfaction.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> One minor formatting request -  the "Table X" titles
> > > >>>>>>>>>>>>>> associated with each
> > > >>>>>>>>>>>>> table appear centered in the .txt file - but are left
> > > >>>>>>>>>>>>> aligned (at the table
> > > >>>>>>>>>>>>> boundary) in the PDF and HTML files.
> > > >>>>>>>>>>>>>> Is it possible to have them centered in the PDF/HTML files
> > > >>>>>>>>>>>>>> as well?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> In regards to Question 14b - sorry for overlooking that.
> > > >>>>>>>>>>>>>> When I began work on the bis version, I noted that the
> > > >>>>>>>>>>>>>> Errata that had been
> > > >>>>>>>>>>>>> filed had a cut and paste error - there actually were no
> > > >>>>>>>>>>>>> changes required to
> > > >>>>>>>>>>>>> Section 6.2 - but I had mistakenly cut and pasted the
> > > >>>>>>>>>>>>> changes for Section 4.2 a
> > > >>>>>>>>>>>>> second time as if they should also be applied to Section
> > > >>>>>>>>>>>>> 6.2.
> > > >>>>>>>>>>>>>> No one noticed this when discussing the Errata - and since
> > > >>>>>>>>>>>>>> the Errata is
> > > >>>>>>>>>>>>> formally marked as rejected (in favor of doing a bis version
> > > >>>>>>>>>>>>> of the RFC) I saw
> > > >>>>>>>>>>>>> no reason to correct the already rejected Errata.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Bravo to you for noticing this - but this is why there are
> > > >>>>>>>>>>>>>> no changes to
> > > >>>>>>>>>>>>> Section 6.2. 😊
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Other than the minor format correction mentioned above,
> > > >>>>>>>>>>>>>> this latest version
> > > >>>>>>>>>>>>> has my approval.
> > > >>>>>>>>>>>>>> Thanx for all that you do.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Les
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> -----Original Message-----
> > > >>>>>>>>>>>>>>> From: Lynne Bartholomew <[e-mail]>
> > > >>>>>>>>>>>>>>> Sent: Wednesday, September 27, 2023 1:42 PM
> > > >>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>; Acee
> > > >>>>>>>>>>>>>>> Lindem
> > > >>>>>>>>>>>>>>> <[e-mail]>
> > > >>>>>>>>>>>>>>> Cc: [e-mail]; Peter Psenak (ppsenak)
> > > >>>>>>>>>>>>> <[e-mail]>;
> > > >>>>>>>>>>>>>>> [e-mail]; [e-mail];
> > > >>>>>>>>>>>>>>> [e-mail]; lsr-
> > > >>>>>>>>>>>>>>> [e-mail]; [e-mail]; [e-mail];
> > > >>>>>>>>>>>>>>> [e-mail];
> > > >>>>>>>>>>>>>>> [e-mail]
> > > >>>>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
> > > >>>>>>>>>>>>>>> rfc8919bis-04> for
> > > >>>>>>>>>>>>> your
> > > >>>>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Hi, Les and Acee.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Thank you for the emails.  Les, thank you for your
> > > >>>>>>>>>>>>>>> thorough review and
> > > >>>>>>>>>>>>> replies
> > > >>>>>>>>>>>>>>> to our questions.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Les, we took a look at the five most recent RFCs that
> > > >>>>>>>>>>>>>>> obsolete other RFCs
> > > >>>>>>>>>>>>>>> (RFCs 9399, 9411, 9436, 9438, and 9457) and found
> that
> > > in
> > > >>>>>>>>>>>>>>> all five cases
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>> RFC or RFCs being obsoleted were listed under
> Informative
> > > >>>>>>>>>>>>>>> References. As
> > > >>>>>>>>>>>>> you
> > > >>>>>>>>>>>>>>> noted below, Informative Reference is indeed the
> > > >>>>>>>>>>>>>>> appropriate choice here as
> > > >>>>>>>>>>>>>>> well, and we've moved the listing accordingly.  Apologies
> > > >>>>>>>>>>>>>>> for any confusion.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Please advise re. our question 14)b):
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> b) We see that the "NEW" text for Section 4.2 was
> > > >>>>>>>>>>>>>>>>> applied per
> > > >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/errata/eid6630> but the
> > > >>>>>>>>>>>>>>>>> "NEW" text for
> > > >>>>>>>>>>>>>>>>> Section 6.2 was not.  Is this as desired (i.e., does
> > > >>>>>>>>>>>>>>>>> "subject to the
> > > >>>>>>>>>>>>>>>>> restrictions specified in Section 4.2" in the first
> > > >>>>>>>>>>>>>>>>> paragraph of
> > > >>>>>>>>>>>>>>>>> Section 6.2 handle the erratum information
> > > adequately?)?
> > > >>>>>>>>>>>>>>>>> -->
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> The latest files are posted here (please refresh your
> > > >>>>>>>>>>>>>>> browser):
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-
> > > auth48diff.html
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-
> xmldiff1.html
> > > >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-
> xmldiff2.html
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Please review our updates carefully, and let us know if
> > > >>>>>>>>>>>>>>> anything is incorrect
> > > >>>>>>>>>>>>> or
> > > >>>>>>>>>>>>>>> we missed anything.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Thanks again!
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> RFC Editor/lb
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Sep 26, 2023, at 8:11 AM, Les Ginsberg (ginsberg)
> > > >>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Acee -
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I agree - but at most this is only informational.
> > > >>>>>>>>>>>>>>>> The discussion of what changed from RFC 8919 is
> > > >>>>>>>>>>>>>>>> informative from a
> > > >>>>>>>>>>>>>>> historical perspective - and may be useful to
> implementors
> > > >>>>>>>>>>>>>>> who wrote code
> > > >>>>>>>>>>>>>>> based on RFC 8919 and want to check whether they
> need to
> > > >>>>>>>>>>>>>>> make any
> > > >>>>>>>>>>>>>>> changes to be conformant to RFC 9479, but RFC 9479
> > > should
> > > >>>>>>>>>>>>>>> stand on its
> > > >>>>>>>>>>>>>>> own. If an implementor never knew of the existence of
> RFC
> > > >>>>>>>>>>>>>>> 8919 it should
> > > >>>>>>>>>>>>> not
> > > >>>>>>>>>>>>>>> matter.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> So maybe Informative Reference is the appropriate
> choice
> > > >>>>>>>>>>>>>>>> here?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Les
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Sep 26, 2023, at 7:55 AM, Acee Lindem
> > > >>>>>>>>>>>>>>>> <[e-mail]> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I think it is common practice to reference the obsoleted
> > > >>>>>>>>>>>>>>>> draft in the
> > > >>>>>>>>>>>>>>> “Differences from RFCxxxx” text.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>> Acee
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Sep 25, 2023, at 8:13 PM, Les Ginsberg (ginsberg)
> > > >>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> And one other issue, highlighted in the review of
> > > >>>>>>>>>>>>>>>> RFC8920bis (to become
> > > >>>>>>>>>>>>>>> RFC9492)
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> References to:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [SEGMENT-ROUTING]
> > > >>>>>>>>>>>>>>>>  Filsfils, C., Talaulikar, K., Ed., Voyer, D.,
> > > >>>>>>>>>>>>>>>> Bogdanov,
> > > >>>>>>>>>>>>>>>>  A., and P. Mattes, "Segment Routing Policy
> > > >>>>>>>>>>>>>>>> Architecture",
> > > >>>>>>>>>>>>>>>>  RFC 9256, DOI 10.17487/RFC9256, July 2022,
> > > >>>>>>>>>>>>>>>>  <https://www.rfc-editor.org/info/rfc9256>.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Need to be changed to use [RFC9256].
> > > >>>>>>>>>>>>>>>> The name [SEGMENT_ROUTING] occurs because when
> RFC
> > > 8919
> > > >>>>>>>>>>>>>>>> was
> > > >>>>>>>>>>>>>>> published RFC9256 did not exist - it was still in draft
> > > >>>>>>>>>>>>>>> form.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Les
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Sep 25, 2023, at 7:50 PM, Les Ginsberg (ginsberg)
> > > >>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> One correction to my responses:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Given that this document obsoletes RFC8919, it seems
> > > >>>>>>>>>>>>>>>> inappropriate to
> > > >>>>>>>>>>>>>>> include RFC 8919 as a reference at all.
> > > >>>>>>>>>>>>>>>> At a minimum, it seems odd to have an obsoleted
> > > document
> > > >>>>>>>>>>>>>>>> as a
> > > >>>>>>>>>>>>> Normative
> > > >>>>>>>>>>>>>>> Reference.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> What is the correct policy here?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> (Sorry for missing this earlier)
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Les
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Sep 25, 2023, at 3:39 PM, Les Ginsberg (ginsberg)
> > > >>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Folks -
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Please find my responses to your questions inline
> below.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> -----Original Message-----
> > > >>>>>>>>>>>>>>>>> From: [e-mail] <rfc-editor@rfc-
> > > >>>>>>>>>>>>>>>>> editor.org>
> > > >>>>>>>>>>>>>>>>> Sent: Monday, September 11, 2023 2:59 PM
> > > >>>>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>;
> Peter
> > > >>>>>>>>>>>>>>>>> Psenak
> > > >>>>>>>>>>>>> (ppsenak)
> > > >>>>>>>>>>>>>>>>> <[e-mail]>; [e-mail];
> > > >>>>>>>>>>>>> [e-mail];
> > > >>>>>>>>>>>>>>>>> [e-mail]
> > > >>>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail]; lsr-
> > > >>>>>>>>>>>>>>>>> [e-mail];
> > > >>>>>>>>>>>>>>>>> [e-mail]; [e-mail];
> > > auth48archive@rfc-
> > > >>>>>>>>>>>>>>>>> editor.org
> > > >>>>>>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
> > > >>>>>>>>>>>>>>>>> rfc8919bis-04> for
> > > >>>>>>>>>>>>>>> your
> > > >>>>>>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Authors,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> While reviewing this document during AUTH48, please
> > > >>>>>>>>>>>>>>>>> resolve (as
> > > >>>>>>>>>>>>>>> necessary)
> > > >>>>>>>>>>>>>>>>> the following questions, which are also in the XML file.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 1) <!-- [rfced] Please note that because the XML file
> > > >>>>>>>>>>>>>>>>> for this document
> > > >>>>>>>>>>>>>>>>> was submitted in "prepped" format, we created a
> > > >>>>>>>>>>>>>>>>> "nonprepped" copy of
> > > >>>>>>>>>>>>>>>>> the file in order to edit the document properly.  This
> > > >>>>>>>>>>>>>>>>> does not
> > > >>>>>>>>>>>>>>>>> impact the document's text but resulted in many
> changes
> > > >>>>>>>>>>>>>>>>> to the XML
> > > >>>>>>>>>>>>>>>>> code (as can be viewed in the "xmldiff" files that will
> > > >>>>>>>>>>>>>>>>> be provided
> > > >>>>>>>>>>>>>>>>> when this document moves to the AUTH48 state). -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] Understood. Out of an abundance of caution I
> > > >>>>>>>>>>>>>>>> started with the XML
> > > >>>>>>>>>>>>>>> available from Datatracker for RFC 8919. It had a number
> > > >>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>> "strangenesses"
> > > >>>>>>>>>>>>>>> (at least to me) - but I chose not to modify them as I
> > > >>>>>>>>>>>>>>> wanted the
> > > >>>>>>>>>>>>> text/format
> > > >>>>>>>>>>>>>>> to be as close as possible to RFC 8919.
> > > >>>>>>>>>>>>>>>> I wish there had been a more "up to date" version of
> the
> > > >>>>>>>>>>>>>>>> XML for me to
> > > >>>>>>>>>>>>> start
> > > >>>>>>>>>>>>>>> with - but there was not.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond
> those
> > > >>>>>>>>>>>>>>>>> that appear in
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> title) for use on <https://www.rfc-editor.org/search>.
> > > >>>>>>>>>>>>>>>>> -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] None added.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 3) <!-- [rfced] Section 2:  Please confirm that the
> > > >>>>>>>>>>>>>>>>> citation for
> > > >>>>>>>>>>>>>>>>> RFC 7855 ("Source Packet Routing in Networking
> > > (SPRING)
> > > >>>>>>>>>>>>>>>>> Problem
> > > >>>>>>>>>>>>>>>>> Statement and Requirements") is correct and will be
> > > >>>>>>>>>>>>>>>>> clear to readers.
> > > >>>>>>>>>>>>>>>>> We are unsure if "Source Packet Routing" and
> "Segment
> > > >>>>>>>>>>>>>>>>> Routing" mean
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> same thing.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] It is fine as is. Segment Routing is an instance
> > > >>>>>>>>>>>>>>>> of the more general
> > > >>>>>>>>>>>>>>> concept of "Source Packet Routing".
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> [RFC7855] discusses use cases and requirements for
> > > >>>>>>>>>>>>>>>>> Segment Routing
> > > >>>>>>>>>>>>>>>>> (SR). -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 4) <!-- [rfced] Sections 3 and subsequent:  We see that
> > > >>>>>>>>>>>>>>>>> the instances of
> > > >>>>>>>>>>>>>>>>> "TLVs 22, 23, 25, 141, 222, and 223" in RFC 8919
> have
> > > >>>>>>>>>>>>>>>>> been replaced
> > > >>>>>>>>>>>>>>>>> by "TLVs Advertising Neighbor Information" in running
> > > >>>>>>>>>>>>>>>>> text in this
> > > >>>>>>>>>>>>>>>>> document.  In some places, the new text reads oddly.
> > > >>>>>>>>>>>>>>>>> Should "TLVs
> > > >>>>>>>>>>>>>>>>> Advertising Neighbor Information" be "TLVs
> advertising
> > > >>>>>>>>>>>>>>>>> neighbor
> > > >>>>>>>>>>>>>>>>> information", as is done in the text on
> > > >>>>>>>>>>>>>>>>> <https://www.iana.org/assignments/isis-tlv-
> > > codepoints/>?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] I have looked at the use cases - I think the text
> > > >>>>>>>>>>>>>>>> is fine as is.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> Existing advertisements used in support of RSVP-TE
> > > >>>>>>>>>>>>>>>>> include sub-TLVs
> > > >>>>>>>>>>>>>>>>> for TLVs Advertising Neighbor Information and TLVs for
> > > >>>>>>>>>>>>>>>>> Shared Risk
> > > >>>>>>>>>>>>>>>>> Link Group (SRLG) advertisement.
> > > >>>>>>>>>>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>> 1)  Application-Specific Link Attributes sub-TLV for
> > > >>>>>>>>>>>>>>>>> TLVs Advertising
> > > >>>>>>>>>>>>>>>>> Neighbor Information (defined in Section 4.2).
> > > >>>>>>>>>>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>> A new sub-TLV for TLVs Advertising Neighbor
> Information
> > > >>>>>>>>>>>>>>>>> is defined
> > > >>>>>>>>>>>>>>>>> that supports specification of the applications and
> > > >>>>>>>>>>>>>>>>> application-
> > > >>>>>>>>>>>>>>>>> specific attribute values.
> > > >>>>>>>>>>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>> When the L-flag is set in the Application Identifier Bit
> > > >>>>>>>>>>>>>>>>> Mask, all of
> > > >>>>>>>>>>>>>>>>> the applications specified in the bit mask MUST use
> the
> > > >>>>>>>>>>>>>>>>> legacy
> > > >>>>>>>>>>>>>>>>> advertisements for the corresponding link found in
> TLVs
> > > >>>>>>>>>>>>>>>>> Advertising
> > > >>>>>>>>>>>>>>>>> Neighbor Information. -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 5) <!--[rfced] Tables 1 and 5: We have changed "TE
> > > >>>>>>>>>>>>>>>>> Default Metric" to
> > > >>>>>>>>>>>>>>>>> "TE Default metric" per RFC 5305. We will ask that
> IANA
> > > >>>>>>>>>>>>>>>>> make this
> > > >>>>>>>>>>>>>>>>> capitalization consistent in its registies prior to
> > > >>>>>>>>>>>>>>>>> publication.
> > > >>>>>>>>>>>>>>>>> Please let us know of any objections. -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] No objection
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 6) <!-- [rfced] We see that Table 1 has a title but
> > > >>>>>>>>>>>>>>>>> Tables 2 through 7
> > > >>>>>>>>>>>>>>>>> do not.  Would you like all of the tables to have
> > > >>>>>>>>>>>>>>>>> titles?  If yes,
> > > >>>>>>>>>>>>>>>>> please provide them.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] Honestly, I think there is no need for a title for
> > > >>>>>>>>>>>>>>>> any of the tables - it is
> > > >>>>>>>>>>>>>>> the table format that is useful for presentation.
> > > >>>>>>>>>>>>>>>> So my choice would be to remove the title for Table I.
> > > >>>>>>>>>>>>>>>> If you insist, I can come up with names for the other
> > > >>>>>>>>>>>>>>>> tables, but I don’t
> > > >>>>>>>>>>>>> think
> > > >>>>>>>>>>>>>>> they add any value.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> Table 1: Sub-TLVs for TLVs Advertising
> > > >>>>>>>>>>>>>>>>> Neighbor Information
> > > >>>>>>>>>>>>>>>>> Table 2
> > > >>>>>>>>>>>>>>>>> Table 3
> > > >>>>>>>>>>>>>>>>> Table 4
> > > >>>>>>>>>>>>>>>>> Table 5
> > > >>>>>>>>>>>>>>>>> Table 6
> > > >>>>>>>>>>>>>>>>> Table 7 -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 7) <!-- [rfced] Section 4.1:  Should the section title
> > > >>>>>>>>>>>>>>>>> be "Application
> > > >>>>>>>>>>>>>>>>> Identifier Bit Masks" or "Application Identifier Bit
> > > >>>>>>>>>>>>>>>>> Mask Types"?
> > > >>>>>>>>>>>>>>>>> We ask because we see "two bit masks" in the
> sentence
> > > >>>>>>>>>>>>>>>>> that follows,
> > > >>>>>>>>>>>>>>>>> as well as "zero-length Application Identifier Bit
> > > >>>>>>>>>>>>>>>>> Masks" elsewhere.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] Title is fine as is.
> > > >>>>>>>>>>>>>>>> Application Identifier Bit Masks is the name of the set
> > > >>>>>>>>>>>>>>>> of fields (SABM
> > > >>>>>>>>>>>>>>> Length, UDABM Length, SABM bit mask, UDABM bit
> mask)
> > > which
> > > >>>>>>>>>>>>>>> are
> > > >>>>>>>>>>>>> encoded
> > > >>>>>>>>>>>>>>> in the ASLA sub-TLV.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> 4.1.  Application Identifier Bit Mask -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 8) <!-- [rfced] Sections 4.2 and 4.3:  We cannot tell
> > > >>>>>>>>>>>>>>>>> whether "SABM" in
> > > >>>>>>>>>>>>>>>>> these sentences refers to the SABM field or the SABM
> > > >>>>>>>>>>>>>>>>> Length field.
> > > >>>>>>>>>>>>>>>>> Will these sentences be clear to readers, or should
> > > >>>>>>>>>>>>>>>>> "SABM or UDABM
> > > >>>>>>>>>>>>>>>>> Length" be "SABM Length or UDABM Length"?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] It is probably clearer to say "SABM Length or
> > > >>>>>>>>>>>>>>>> UDABM length"
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> If the SABM or UDABM Length in the Application
> > > >>>>>>>>>>>>>>>>> Identifier Bit Mask is
> > > >>>>>>>>>>>>>>>>> greater than 8, the entire sub-TLV MUST be ignored.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> When SABM or UDABM Length is non-zero and the L-
> flag
> > > is
> > > >>>>>>>>>>>>>>>>> NOT set, all
> > > >>>>>>>>>>>>>>>>> applications specified in the bit mask MUST use the
> link
> > > >>>>>>>>>>>>>>>>> attribute
> > > >>>>>>>>>>>>>>>>> advertisements in the sub-TLV.
> > > >>>>>>>>>>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>> If the SABM or UDABM Length in the Application
> > > >>>>>>>>>>>>>>>>> Identifier Bit Mask is
> > > >>>>>>>>>>>>>>>>> greater than 8, the entire sub-TLV MUST be ignored.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> When SABM or UDABM Length is non-zero and the L-
> flag
> > > is
> > > >>>>>>>>>>>>>>>>> NOT set, all
> > > >>>>>>>>>>>>>>>>> applications specified in the bit mask MUST use SRLG
> > > >>>>>>>>>>>>>>>>> advertisements
> > > >>>>>>>>>>>>>>>>> in the Application-Specific SRLG TLV. -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 9) <!-- [rfced] Section 4.2:  For ease of the reader,
> > > >>>>>>>>>>>>>>>>> should "LSP" be
> > > >>>>>>>>>>>>>>>>> defined as "Label-Switched Path" per RFC 3209 or
> "Link
> > > >>>>>>>>>>>>>>>>> State Protocol
> > > >>>>>>>>>>>>>>>>> Data Unit" per RFC 5305?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] "Link State Protocol Data Unit"
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> In cases where conflicting values for the same
> > > >>>>>>>>>>>>>>>>> application/attribute/link are advertised, the first
> > > >>>>>>>>>>>>>>>>> advertisement
> > > >>>>>>>>>>>>>>>>> received in the lowest-numbered LSP MUST be used,
> and
> > > >>>>>>>>>>>>>>>>> subsequent
> > > >>>>>>>>>>>>>>>>> advertisements of the same attribute MUST be
> ignored.
> > > >>>>>>>>>>>>>>>>> -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 10) <!-- [rfced] Section 4.3:  As it appears that "a
> > > >>>>>>>>>>>>>>>>> single TLV" refers
> > > >>>>>>>>>>>>>>>>> to the new Application-Specific SRLG TLV and not to
> some
> > > >>>>>>>>>>>>>>>>> other type
> > > >>>>>>>>>>>>>>>>> of TLV, we changed "a single TLV" to "this new single
> > > >>>>>>>>>>>>>>>>> TLV" here.
> > > >>>>>>>>>>>>>>>>> If this is incorrect, please provide clarifying text.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] This is fine.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original (the previous sentence is included for
> > > >>>>>>>>>>>>>>>>> context):
> > > >>>>>>>>>>>>>>>>> A new TLV is defined to advertise application-specific
> > > >>>>>>>>>>>>>>>>> SRLGs for a
> > > >>>>>>>>>>>>>>>>> given link.  Although similar in functionality to TLV
> > > >>>>>>>>>>>>>>>>> 138 [RFC5307]
> > > >>>>>>>>>>>>>>>>> and TLV 139 [RFC6119], a single TLV provides support
> for
> > > >>>>>>>>>>>>>>>>> IPv4, IPv6,
> > > >>>>>>>>>>>>>>>>> and unnumbered identifiers for a link.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Currently:
> > > >>>>>>>>>>>>>>>>> Although similar in functionality to TLV 138 [RFC5307]
> > > >>>>>>>>>>>>>>>>> and TLV 139 [RFC6119], this new single TLV provides
> > > >>>>>>>>>>>>>>>>> support for IPv4,
> > > >>>>>>>>>>>>>>>>> IPv6, and unnumbered identifiers for a link. -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 11) <!-- [rfced] Sections 5 and 6:  We changed
> > > >>>>>>>>>>>>>>>>> lowercased instances of
> > > >>>>>>>>>>>>>>>>> "application-specific link attribute(s)" to "ASLA(s)"
> > > >>>>>>>>>>>>>>>>> per the
> > > >>>>>>>>>>>>>>>>> expansion provided in Section 4.  Please review, and let
> > > >>>>>>>>>>>>>>>>> us know any
> > > >>>>>>>>>>>>>>>>> objections. -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] No objection
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 12) <!-- [rfced] Sections 5 and subsequent:  The
> > > >>>>>>>>>>>>>>>>> following instances of
> > > >>>>>>>>>>>>>>>>> "LFA" in these sentences read oddly.  Should they be
> > > >>>>>>>>>>>>>>>>> plural or
> > > >>>>>>>>>>>>>>>>> perhaps "LFA Policy"?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] "LFA" is correct. This refers to the application
> > > >>>>>>>>>>>>>>>> types defined in
> > > >>>>>>>>>>>>> Section
> > > >>>>>>>>>>>>>>> 4.1
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> In the case of LFA, the advertisement of application-
> > > >>>>>>>>>>>>>>>>> specific link
> > > >>>>>>>>>>>>>>>>> attributes does not indicate enablement of LFA on that
> > > >>>>>>>>>>>>>>>>> link.
> > > >>>>>>>>>>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>> *  The application is SR Policy or LFA, and RSVP-TE is
> > > >>>>>>>>>>>>>>>>> not deployed
> > > >>>>>>>>>>>>>>>>> anywhere in the network.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  The application is SR Policy or LFA, RSVP-TE is
> > > >>>>>>>>>>>>>>>>> deployed in the
> > > >>>>>>>>>>>>>>>>> network, and both the set of links on which SR Policy
> > > >>>>>>>>>>>>>>>>> and/or LFA
> > > >>>>>>>>>>>>>>>>> advertisements are required and the attribute values
> > > >>>>>>>>>>>>>>>>> used by SR
> > > >>>>>>>>>>>>>>>>> Policy and/or LFA on all such links are fully congruent
> > > >>>>>>>>>>>>>>>>> with the
> > > >>>>>>>>>>>>>>>>> links and attribute values used by RSVP-TE.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Under the conditions defined above, implementations
> > > that
> > > >>>>>>>>>>>>>>>>> support the
> > > >>>>>>>>>>>>>>>>> extensions defined in this document have the choice
> of
> > > >>>>>>>>>>>>>>>>> using legacy
> > > >>>>>>>>>>>>>>>>> advertisements or application-specific advertisements
> in
> > > >>>>>>>>>>>>>>>>> support of
> > > >>>>>>>>>>>>>>>>> SR Policy and/or LFA.
> > > >>>>>>>>>>>>>>>>> ...
> > > >>>>>>>>>>>>>>>>> Existing deployments of RSVP-TE, SR Policy, and/or LFA
> > > >>>>>>>>>>>>>>>>> utilize the
> > > >>>>>>>>>>>>>>>>> legacy advertisements listed in Section 3. -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 13) <!-- [rfced] Section 5:  Per previous text in this
> > > >>>>>>>>>>>>>>>>> document, we
> > > >>>>>>>>>>>>>>>>> changed "advertisement of link attribute
> advertisements"
> > > >>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> "advertisement of link attributes".  If this is
> > > >>>>>>>>>>>>>>>>> incorrect, please
> > > >>>>>>>>>>>>>>>>> provide alternative text.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] This is fine.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original:
> > > >>>>>>>>>>>>>>>>> In the presence of
> > > >>>>>>>>>>>>>>>>> an application where the advertisement of link
> attribute
> > > >>>>>>>>>>>>>>>>> advertisements is used to infer the enablement of an
> > > >>>>>>>>>>>>>>>>> application on
> > > >>>>>>>>>>>>>>>>> that link (e.g., RSVP-TE), the absence of the
> > > >>>>>>>>>>>>>>>>> application identifier
> > > >>>>>>>>>>>>>>>>> leaves ambiguous whether that application is enabled
> on
> > > >>>>>>>>>>>>>>>>> such a link.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Currently:
> > > >>>>>>>>>>>>>>>>> In the presence of
> > > >>>>>>>>>>>>>>>>> an application where the advertisement of link
> > > >>>>>>>>>>>>>>>>> attributes is used to
> > > >>>>>>>>>>>>>>>>> infer the enablement of an application on that link
> > > >>>>>>>>>>>>>>>>> (e.g., RSVP-TE),
> > > >>>>>>>>>>>>>>>>> the absence of the application identifier leaves
> > > >>>>>>>>>>>>>>>>> ambiguous whether
> > > >>>>>>>>>>>>>>>>> that application is enabled on such a link. -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 14) <!-- [rfced] Section 9:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> a) We could not locate the discussion in question via
> > > >>>>>>>>>>>>>>>>> the information
> > > >>>>>>>>>>>>>>>>> in the current text.  Searching by thread on
> > > >>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/browse/lsr/> for
> > > >>>>>>>>>>>>>>>>> "Proposed Errata for RFCs 8919/8920" directed us to
> > > >>>>>>>>>>>>>>>>> <https://mailarchive.ietf.org/arch/>, which provides
> an
> > > >>>>>>>>>>>>>>>>> "Enter list name or search query..." box, which did not
> > > >>>>>>>>>>>>>>>>> yield the
> > > >>>>>>>>>>>>>>>>> desired information.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] The removal of the URL was done based on
> feedback
> > > >>>>>>>>>>>>>>>> during IESG
> > > >>>>>>>>>>>>>>> review. IT was commented that any such URL might not
> be
> > > >>>>>>>>>>>>>>> valid
> > > >>>>>>>>>>>>> indefinitely.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> When I put "Proposed Errata for RFCs 8919/8920" into
> the
> > > >>>>>>>>>>>>>>>> search bar at
> > > >>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/lsr/ I do find
> > > >>>>>>>>>>>>>>> the relevant thread.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> However, when looking at <https://www.rfc-
> > > >>>>>>>>>>>>>>>>> editor.org/errata/eid6630>
> > > >>>>>>>>>>>>>>>>> (the erratum page for RFC 8919), we found
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > >
> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/
> > > >>>>>>>>>>>>>>>>>> .
> > > >>>>>>>>>>>>>>>>> Would pointing to this link instead of 'the thread
> > > >>>>>>>>>>>>>>>>> "Proposed Errata
> > > >>>>>>>>>>>>>>>>> for RFCs 8919/8920"' be acceptable?  If not, please
> > > >>>>>>>>>>>>>>>>> provide a URL
> > > >>>>>>>>>>>>>>>>> that can be listed as a good starting point for readers
> > > >>>>>>>>>>>>>>>>> interested in
> > > >>>>>>>>>>>>>>>>> this information.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Original (the previous sentence is included for
> > > >>>>>>>>>>>>>>>>> context):
> > > >>>>>>>>>>>>>>>>> Discussion within the LSR WG indicated that there was
> > > >>>>>>>>>>>>>>>>> confusion
> > > >>>>>>>>>>>>>>>>> regarding the use of ASLA advertisements that had a
> zero
> > > >>>>>>>>>>>>>>>>> length SABM/
> > > >>>>>>>>>>>>>>>>> UDABM.  The discussion can be seen by searching the
> LSR
> > > >>>>>>>>>>>>>>>>> WG mailing
> > > >>>>>>>>>>>>>>>>> list archives for the thread "Proposed Errata for RFCs
> > > >>>>>>>>>>>>>>>>> 8919/8920"
> > > >>>>>>>>>>>>>>>>> starting on 15 June 2021.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Possibly:
> > > >>>>>>>>>>>>>>>>> Discussion within the LSR WG indicated that there was
> > > >>>>>>>>>>>>>>>>> confusion
> > > >>>>>>>>>>>>>>>>> regarding the use of ASLA advertisements that had a
> > > >>>>>>>>>>>>>>>>> zero-length SABM/
> > > >>>>>>>>>>>>>>>>> UDABM.  The discussion can be seen on
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > >
> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/
> > > >>>>>>>>>>>>>>>>>> .
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> b) We see that the "NEW" text for Section 4.2 was
> > > >>>>>>>>>>>>>>>>> applied per
> > > >>>>>>>>>>>>>>>>> <https://www.rfc-editor.org/errata/eid6630> but the
> > > >>>>>>>>>>>>>>>>> "NEW" text for
> > > >>>>>>>>>>>>>>>>> Section 6.2 was not.  Is this as desired (i.e., does
> > > >>>>>>>>>>>>>>>>> "subject to the
> > > >>>>>>>>>>>>>>>>> restrictions specified in Section 4.2" in the first
> > > >>>>>>>>>>>>>>>>> paragraph of
> > > >>>>>>>>>>>>>>>>> Section 6.2 handle the erratum information
> > > adequately?)?
> > > >>>>>>>>>>>>>>>>> -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 15) <!-- [rfced] We added RFC 8919 to the list of
> > > >>>>>>>>>>>>>>>>> Normative References.
> > > >>>>>>>>>>>>>>>>> Please let us know if it should be an Informative
> > > >>>>>>>>>>>>>>>>> Reference instead.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] Fine as a normative reference.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 16) <!-- [rfced] Please review the "Inclusive Language"
> > > >>>>>>>>>>>>>>>>> portion of the
> > > >>>>>>>>>>>>>>>>> online Style Guide at
> > > >>>>>>>>>>>>>>>>> <https://www.rfc-
> > > >>>>>>>>>>>>>>>>> editor.org/styleguide/part2/#inclusive_language>,
> > > >>>>>>>>>>>>>>>>> and let us know if any changes are needed.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Note that our script did not flag any words in
> > > >>>>>>>>>>>>>>>>> particular, but this
> > > >>>>>>>>>>>>>>>>> should still be reviewed as a best practice. -->
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] No changes are needed that I can see.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 17) <!-- [rfced] The following term appears to be used
> > > >>>>>>>>>>>>>>>>> inconsistently in
> > > >>>>>>>>>>>>>>>>> this document.  Please let us know which form is
> > > >>>>>>>>>>>>>>>>> preferred.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [LES:] Please use lower case "legacy".
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Les
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Legacy sub-TLV / legacy sub-TLV (text in Section 4.2)
> > > >>>>>>>>>>>>>>>>> -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Thank you.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> RFC Editor/lb/ap
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Sep 25, 2023, at 3:10 PM, Les Ginsberg (ginsberg)
> > > >>>>>>>>>>>>>>> <ginsberg=[e-mail]> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Folks -
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I am fine with the changes introduced with the
> following
> > > >>>>>>>>>>>>>>>> exceptions:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 1)Section 6.3.3
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> "while continuing to use legacy advertisements"
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Please change this to
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> "while continuing to advertise legacy advertisements"
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> The point is to indicate that both forms need to be
> > > >>>>>>>>>>>>>>>> advertised(sic).
> > > >>>>>>>>>>>>>>>> The last sentence in the paragraph clearly states what is
> > > >>>>>>>>>>>>>>>> used.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 2)Section 7.2
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> You have changed column #2 to be "Name" - but the
> > > >>>>>>>>>>>>>>>> corresponding
> > > >>>>>>>>>>>>> registry
> > > >>>>>>>>>>>>>>> uses the original term "Description".
> > > >>>>>>>>>>>>>>>> Please revert this change.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 3)Section 7.5
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> You changed the title to "IS-IS Sub-TLVs for Application-
> > > >>>>>>>>>>>>>>>> Specific SRLG TLV
> > > >>>>>>>>>>>>>>> Registry (for TLV 238)".
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> This does not match the title in the registry:
> > > >>>>>>>>>>>>>>> https://www.iana.org/assignments/isis-tlv-
> codepoints/isis-
> > > >>>>>>>>>>>>>>> tlv-
> > > >>>>>>>>>>>>>>> codepoints.xhtml#tlv-238
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> "IS-IS Sub-TLVs for Application-Specific SRLG TLV"
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Les
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> -----Original Message-----
> > > >>>>>>>>>>>>>>>>> From: [e-mail] <rfc-editor@rfc-
> > > >>>>>>>>>>>>>>>>> editor.org>
> > > >>>>>>>>>>>>>>>>> Sent: Monday, September 11, 2023 2:57 PM
> > > >>>>>>>>>>>>>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>;
> Peter
> > > >>>>>>>>>>>>>>>>> Psenak
> > > >>>>>>>>>>>>> (ppsenak)
> > > >>>>>>>>>>>>>>>>> <[e-mail]>; [e-mail];
> > > >>>>>>>>>>>>> [e-mail];
> > > >>>>>>>>>>>>>>>>> [e-mail]
> > > >>>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail]; lsr-
> > > >>>>>>>>>>>>>>>>> [e-mail];
> > > >>>>>>>>>>>>>>>>> [e-mail]; [e-mail];
> > > auth48archive@rfc-
> > > >>>>>>>>>>>>>>>>> editor.org
> > > >>>>>>>>>>>>>>>>> Subject: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-
> > > >>>>>>>>>>>>>>>>> rfc8919bis-04> for your
> > > >>>>>>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *****IMPORTANT*****
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Updated 2023/09/11
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> RFC Author(s):
> > > >>>>>>>>>>>>>>>>> --------------
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Instructions for Completing AUTH48
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Your document has now entered AUTH48.  Once it has
> > > been
> > > >>>>>>>>>>>>>>>>> reviewed
> > > >>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>> approved by you and all coauthors, it will be published
> > > >>>>>>>>>>>>>>>>> as an RFC.
> > > >>>>>>>>>>>>>>>>> If an author is no longer available, there are several
> > > >>>>>>>>>>>>>>>>> remedies
> > > >>>>>>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-
> > > >>>>>>>>>>>>>>>>> editor.org/faq/).
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> You and you coauthors are responsible for engaging
> other
> > > >>>>>>>>>>>>>>>>> parties
> > > >>>>>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary
> > > >>>>>>>>>>>>>>>>> before providing
> > > >>>>>>>>>>>>>>>>> your approval.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Planning your review
> > > >>>>>>>>>>>>>>>>> ---------------------
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please review the following aspects of your document:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  RFC Editor questions
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please review and resolve any questions raised by the
> > > >>>>>>>>>>>>>>>>> RFC Editor
> > > >>>>>>>>>>>>>>>>> that have been included in the XML file as comments
> > > >>>>>>>>>>>>>>>>> marked as
> > > >>>>>>>>>>>>>>>>> follows:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> <!-- [rfced] ... -->
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> These questions will also be sent in a subsequent
> email.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  Changes submitted by coauthors
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please ensure that you review any changes submitted
> by
> > > >>>>>>>>>>>>>>>>> your
> > > >>>>>>>>>>>>>>>>> coauthors.  We assume that if you do not speak up
> that
> > > >>>>>>>>>>>>>>>>> you
> > > >>>>>>>>>>>>>>>>> agree to changes submitted by your coauthors.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  Content
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please review the full content of the document, as this
> > > >>>>>>>>>>>>>>>>> cannot
> > > >>>>>>>>>>>>>>>>> change once the RFC is published.  Please pay
> particular
> > > >>>>>>>>>>>>>>>>> attention to:
> > > >>>>>>>>>>>>>>>>> - IANA considerations updates (if applicable)
> > > >>>>>>>>>>>>>>>>> - contact information
> > > >>>>>>>>>>>>>>>>> - references
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  Copyright notices and legends
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please review the copyright notice and legends as
> > > >>>>>>>>>>>>>>>>> defined in
> > > >>>>>>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
> > > >>>>>>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/).
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  Semantic markup
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please review the markup in the XML file to ensure
> that
> > > >>>>>>>>>>>>>>>>> elements of
> > > >>>>>>>>>>>>>>>>> content are correctly tagged.  For example, ensure that
> > > >>>>>>>>>>>>>>>>> <sourcecode>
> > > >>>>>>>>>>>>>>>>> and <artwork> are set correctly.  See details at
> > > >>>>>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  Formatted output
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure
> > > >>>>>>>>>>>>>>>>> that the
> > > >>>>>>>>>>>>>>>>> formatted output, as generated from the markup in
> the
> > > >>>>>>>>>>>>>>>>> XML file, is
> > > >>>>>>>>>>>>>>>>> reasonable.  Please note that the TXT will have
> > > >>>>>>>>>>>>>>>>> formatting
> > > >>>>>>>>>>>>>>>>> limitations compared to the PDF and HTML.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Submitting changes
> > > >>>>>>>>>>>>>>>>> ------------------
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> To submit changes, please reply to this email using
> > > >>>>>>>>>>>>>>>>> ‘REPLY ALL’ as all
> > > >>>>>>>>>>>>>>>>> the parties CCed on this message need to see your
> > > >>>>>>>>>>>>>>>>> changes. The parties
> > > >>>>>>>>>>>>>>>>> include:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  your coauthors
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  [e-mail] (the RPC team)
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  other document participants, depending on the
> stream
> > > >>>>>>>>>>>>>>>>> (e.g.,
> > > >>>>>>>>>>>>>>>>> IETF Stream participants are your working group
> chairs,
> > > >>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> responsible ADs, and the document shepherd).
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  [e-mail], which is a new
> archival
> > > >>>>>>>>>>>>>>>>> mailing list
> > > >>>>>>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active
> > > >>>>>>>>>>>>>>>>> discussion
> > > >>>>>>>>>>>>>>>>> list:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  More info:
> > > >>>>>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-
> > > >>>>>>>>>>>>>>>>> announce/yb6lpIGh-
> > > >>>>>>>>>>>>>>>>> 4Q9l2USxIAe6P8O4Zc
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  The archive itself:
> > > >>>>>>>>>>>>>>>>>
> https://mailarchive.ietf.org/arch/browse/auth48archive/
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *  Note: If only absolutely necessary, you may
> > > >>>>>>>>>>>>>>>>> temporarily opt out
> > > >>>>>>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a
> > > >>>>>>>>>>>>>>>>> sensitive matter).
> > > >>>>>>>>>>>>>>>>> If needed, please add a note at the top of the message
> > > >>>>>>>>>>>>>>>>> that you
> > > >>>>>>>>>>>>>>>>> have dropped the address. When the discussion is
> > > >>>>>>>>>>>>>>>>> concluded,
> > > >>>>>>>>>>>>>>>>> [e-mail] will be re-added to the
> CC
> > > >>>>>>>>>>>>>>>>> list and
> > > >>>>>>>>>>>>>>>>> its addition will be noted at the top of the message.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> You may submit your changes in one of two ways:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> An update to the provided XML file
> > > >>>>>>>>>>>>>>>>> — OR —
> > > >>>>>>>>>>>>>>>>> An explicit list of changes in this format
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Section # (or indicate Global)
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> OLD:
> > > >>>>>>>>>>>>>>>>> old text
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> NEW:
> > > >>>>>>>>>>>>>>>>> new text
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> You do not need to reply with both an updated XML
> file
> > > >>>>>>>>>>>>>>>>> and an explicit
> > > >>>>>>>>>>>>>>>>> list of changes, as either form is sufficient.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> We will ask a stream manager to review and approve
> any
> > > >>>>>>>>>>>>>>>>> changes that
> > > >>>>>>>>>>>>>>> seem
> > > >>>>>>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text,
> > > >>>>>>>>>>>>>>>>> deletion of text,
> > > >>>>>>>>>>>>>>>>> and technical changes.  Information about stream
> > > >>>>>>>>>>>>>>>>> managers can be
> > > >>>>>>>>>>>>> found
> > > >>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>> the FAQ.  Editorial changes do not require approval
> from
> > > >>>>>>>>>>>>>>>>> a stream
> > > >>>>>>>>>>>>> manager.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Approving for publication
> > > >>>>>>>>>>>>>>>>> --------------------------
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> To approve your RFC for publication, please reply to
> > > >>>>>>>>>>>>>>>>> this email stating
> > > >>>>>>>>>>>>>>>>> that you approve this RFC for publication.  Please use
> > > >>>>>>>>>>>>>>>>> ‘REPLY ALL’,
> > > >>>>>>>>>>>>>>>>> as all the parties CCed on this message need to see
> your
> > > >>>>>>>>>>>>>>>>> approval.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Files
> > > >>>>>>>>>>>>>>>>> -----
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> The files are available here:
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.html
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Diff file of the text:
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-
> rfcdiff.html
> > > >>>>>>>>>>>>>>>>> (side by side)
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Diff of the XML:
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9479-
> > > xmldiff1.html
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Tracking progress
> > > >>>>>>>>>>>>>>>>> -----------------
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> The details of the AUTH48 status of your document
> are
> > > >>>>>>>>>>>>>>>>> here:
> > > >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9479
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Please let us know if you have any questions.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Thank you for your cooperation,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> RFC Editor
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> --------------------------------------
> > > >>>>>>>>>>>>>>>>> RFC9479 (draft-ietf-lsr-rfc8919bis-04)
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Title            : IS-IS Application-Specific Link
> > > >>>>>>>>>>>>>>>>> Attributes
> > > >>>>>>>>>>>>>>>>> Author(s)        : L. Ginsberg, P. Psenak, S. Previdi,
> > > >>>>>>>>>>>>>>>>> W. Henderickx, J. Drake
> > > >>>>>>>>>>>>>>>>> WG Chair(s)      : Acee Lindem, Christian Hopps
> > > >>>>>>>>>>>>>>>>> Area Director(s) : Alvaro Retana, John Scudder,
> Andrew
> > > >>>>>>>>>>>>>>>>> Alston
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > > >
>