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

[Lynne Bartholomew <[e-mail]>]

Hi, Les.  Please see below.  Thank you!

> On Sep 27, 2023, at 3:14 PM, Les Ginsberg (ginsberg) <[e-mail]> wrote:
> 
> Lynne -
> 
> Thanx for the info - it may indeed come in handy in the future - though I hope not to have to do another bis. 😊

Understandable!  I neglected to mention that you can also go straight to <https://www.rfc-editor.org/in-notes/prerelease/> and search for the desired number.

> 
> FYI, I simply downloaded the XML from Datatracker. It is possible what you specify below might have worked - but I assumed whatever was in Datatracker was authoritative.

I did as well but had the same results as you when I downloaded a copy from there.

> Is there a reason why the version in Datatracker is not the editable version? That would certainly be more intuitive from a user retrieval standpoint.

Very good question.  I've asked about this and will let you know what I find out.

> 
>  Les
> 
> 
>> -----Original Message-----
>> From: Lynne Bartholomew <[e-mail]>
>> Sent: Wednesday, September 27, 2023 2:51 PM
>> To: Les Ginsberg (ginsberg) <[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]; Acee Lindem <[e-mail]>
>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your
>> review
>> 
>> Hi, Les.
>> 
>> Re. this item:
>> 
>>>> 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.
>> 
>> We suspect that the ability to download a nonprepped XML file wasn't
>> available at the time that you downloaded the XML copy of RFC 8919, but it is
>> now.  To get a "nonprepped" up-to-date XML copy of a given RFC, you can
>> 
>> * go to <https://www.rfc-editor.org/>
>> * type the desired RFC number in the "Search RFCs" box
>> * click the link in the "Number" column
>> * click the link in the "Also available: XML file for editing" line to get a
>> nonprepped file (e.g., "rfc8919.notprepped") for download
>> 
>> It seems that you write a fair amount of bis documents, so we're hoping that
>> this info. will come in handy in the future.
>> 
>> Thank you for your patience in having worked on a prepped file!
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Sep 27, 2023, at 1:42 PM, Lynne Bartholomew
>> <[e-mail]> wrote:
>>> 
>>> Hi, Les and Acee.
>>> 
>>> Thank you for the emails.  Les, thank you for your thorough review and
>> replies to our questions.
>>> 
>>> Les, we took a look at the five most recent RFCs that obsolete other RFCs
>> (RFCs 9399, 9411, 9436, 9438, and 9457) and found that in all five cases the
>> RFC or RFCs being obsoleted were listed under Informative References. As you
>> noted below, Informative Reference is indeed the appropriate choice here as
>> well, and we've moved the listing accordingly.  Apologies for any confusion.
>>> 
>>> Please advise re. our question 14)b):
>>> 
>>>>> b) We see that the "NEW" text for Section 4.2 was applied per
>>>>> <https://www.rfc-editor.org/errata/eid6630> but the "NEW" text for
>>>>> Section 6.2 was not.  Is this as desired (i.e., does "subject to the
>>>>> restrictions specified in Section 4.2" in the first paragraph of
>>>>> Section 6.2 handle the erratum information adequately?)? -->
>>> 
>>> 
>>> The latest files are posted here (please refresh your browser):
>>> 
>>>  https://www.rfc-editor.org/authors/rfc9479.txt
>>>  https://www.rfc-editor.org/authors/rfc9479.pdf
>>>  https://www.rfc-editor.org/authors/rfc9479.html
>>>  https://www.rfc-editor.org/authors/rfc9479.xml
>>>  https://www.rfc-editor.org/authors/rfc9479-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html
>>>  https://www.rfc-editor.org/authors/rfc9479-auth48diff.html
>>> 
>>>  https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
>>>  https://www.rfc-editor.org/authors/rfc9479-xmldiff2.html
>>> 
>>> Please review our updates carefully, and let us know if anything is incorrect
>> or we missed anything.
>>> 
>>> Thanks again!
>>> 
>>> RFC Editor/lb
>>> 
>>> 
>>>> On Sep 26, 2023, at 8:11 AM, Les Ginsberg (ginsberg)
>> <ginsberg=[e-mail]> wrote:
>>>> 
>>>> Acee -
>>>> 
>>>> 
>>>> I agree - but at most this is only informational.
>>>> The discussion of what changed from RFC 8919 is informative from a
>> historical perspective - and may be useful to implementors who wrote code
>> based on RFC 8919 and want to check whether they need to make any
>> changes to be conformant to RFC 9479, but RFC 9479 should stand on its
>> own. If an implementor never knew of the existence of RFC 8919 it should not
>> matter.
>>>> 
>>>> So maybe Informative Reference is the appropriate choice here?
>>>> 
>>>> Les
>>> 
>>> 
>>> 
>>>> On Sep 26, 2023, at 7:55 AM, Acee Lindem <[e-mail]> wrote:
>>>> 
>>>> I think it is common practice to reference the obsoleted draft in the
>> “Differences from RFCxxxx” text.
>>>> 
>>>> Thanks,
>>>> Acee
>>> 
>>> 
>>> 
>>>> On Sep 25, 2023, at 8:13 PM, Les Ginsberg (ginsberg)
>> <ginsberg=[e-mail]> wrote:
>>>> 
>>>> And one other issue, highlighted in the review of RFC8920bis (to become
>> RFC9492)
>>>> 
>>>> 
>>>> References to:
>>>> 
>>>> [SEGMENT-ROUTING]
>>>>            Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
>>>>            A., and P. Mattes, "Segment Routing Policy Architecture",
>>>>            RFC 9256, DOI 10.17487/RFC9256, July 2022,
>>>>            <https://www.rfc-editor.org/info/rfc9256>.
>>>> 
>>>> Need to be changed to use [RFC9256].
>>>> The name [SEGMENT_ROUTING] occurs because when RFC 8919 was
>> published RFC9256 did not exist - it was still in draft form.
>>>> 
>>>> Les
>>> 
>>> 
>>> 
>>>> On Sep 25, 2023, at 7:50 PM, Les Ginsberg (ginsberg)
>> <ginsberg=[e-mail]> wrote:
>>>> 
>>>> One correction to my responses:
>>>> 
>>>> Given that this document obsoletes RFC8919, it seems inappropriate to
>> include RFC 8919 as a reference at all.
>>>> At a minimum, it seems odd to have an obsoleted document as a
>> Normative Reference.
>>>> 
>>>> What is the correct policy here?
>>>> 
>>>> (Sorry for missing this earlier)
>>>> 
>>>> Les
>>> 
>>> 
>>> 
>>>> On Sep 25, 2023, at 3:39 PM, Les Ginsberg (ginsberg)
>> <ginsberg=[e-mail]> wrote:
>>>> 
>>>> Folks -
>>>> 
>>>> Please find my responses to your questions inline below.
>>>> 
>>>>> -----Original Message-----
>>>>> From: [e-mail] <[e-mail]>
>>>>> Sent: Monday, September 11, 2023 2:59 PM
>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>; Peter Psenak
>> (ppsenak)
>>>>> <[e-mail]>; [e-mail];
>> [e-mail];
>>>>> [e-mail]
>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail]; [e-mail]
>>>>> Subject: Re: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for
>> your
>>>>> review
>>>>> 
>>>>> Authors,
>>>>> 
>>>>> While reviewing this document during AUTH48, please resolve (as
>> necessary)
>>>>> the following questions, which are also in the XML file.
>>>>> 
>>>>> 1) <!-- [rfced] Please note that because the XML file for this document
>>>>> was submitted in "prepped" format, we created a "nonprepped" copy of
>>>>> the file in order to edit the document properly.  This does not
>>>>> impact the document's text but resulted in many changes to the XML
>>>>> code (as can be viewed in the "xmldiff" files that will be provided
>>>>> when this document moves to the AUTH48 state). -->
>>>>> 
>>>> [LES:] Understood. Out of an abundance of caution I started with the XML
>> available from Datatracker for RFC 8919. It had a number of "strangenesses"
>> (at least to me) - but I chose not to modify them as I wanted the text/format
>> to be as close as possible to RFC 8919.
>>>> I wish there had been a more "up to date" version of the XML for me to
>> start with - but there was not.
>>>> 
>>>>> 
>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>>> title) for use on <https://www.rfc-editor.org/search>. -->
>>>>> 
>>>> [LES:] None added.
>>>> 
>>>>> 
>>>>> 3) <!-- [rfced] Section 2:  Please confirm that the citation for
>>>>> RFC 7855 ("Source Packet Routing in Networking (SPRING) Problem
>>>>> Statement and Requirements") is correct and will be clear to readers.
>>>>> We are unsure if "Source Packet Routing" and "Segment Routing" mean
>> the
>>>>> same thing.
>>>>> 
>>>> [LES:] It is fine as is. Segment Routing is an instance of the more general
>> concept of "Source Packet Routing".
>>>> 
>>>>> Original:
>>>>> [RFC7855] discusses use cases and requirements for Segment Routing
>>>>> (SR). -->
>>>>> 
>>>>> 
>>>>> 4) <!-- [rfced] Sections 3 and subsequent:  We see that the instances of
>>>>> "TLVs 22, 23, 25, 141, 222, and 223" in RFC 8919 have been replaced
>>>>> by "TLVs Advertising Neighbor Information" in running text in this
>>>>> document.  In some places, the new text reads oddly.  Should "TLVs
>>>>> Advertising Neighbor Information" be "TLVs advertising neighbor
>>>>> information", as is done in the text on
>>>>> <https://www.iana.org/assignments/isis-tlv-codepoints/>?
>>>>> 
>>>> [LES:] I have looked at the use cases - I think the text is fine as is.
>>>> 
>>>>> Original:
>>>>> Existing advertisements used in support of RSVP-TE include sub-TLVs
>>>>> for TLVs Advertising Neighbor Information and TLVs for Shared Risk
>>>>> Link Group (SRLG) advertisement.
>>>>> ...
>>>>> 1)  Application-Specific Link Attributes sub-TLV for TLVs Advertising
>>>>>   Neighbor Information (defined in Section 4.2).
>>>>> ...
>>>>> A new sub-TLV for TLVs Advertising Neighbor Information is defined
>>>>> that supports specification of the applications and application-
>>>>> specific attribute values.
>>>>> ...
>>>>> When the L-flag is set in the Application Identifier Bit Mask, all of
>>>>> the applications specified in the bit mask MUST use the legacy
>>>>> advertisements for the corresponding link found in TLVs Advertising
>>>>> Neighbor Information. -->
>>>>> 
>>>>> 
>>>>> 5) <!--[rfced] Tables 1 and 5: We have changed "TE Default Metric" to
>>>>> "TE Default metric" per RFC 5305. We will ask that IANA make this
>>>>> capitalization consistent in its registies prior to publication.
>>>>> Please let us know of any objections. -->
>>>>> 
>>>> [LES:] No objection
>>>> 
>>>>> 
>>>>> 6) <!-- [rfced] We see that Table 1 has a title but Tables 2 through 7
>>>>> do not.  Would you like all of the tables to have titles?  If yes,
>>>>> please provide them.
>>>>> 
>>>> [LES:] Honestly, I think there is no need for a title for any of the tables - it is
>> the table format that is useful for presentation.
>>>> So my choice would be to remove the title for Table I.
>>>> If you insist, I can come up with names for the other tables, but I don’t
>> think they add any value.
>>>> 
>>>> 
>>>>> Original:
>>>>> Table 1: Sub-TLVs for TLVs Advertising
>>>>>        Neighbor Information
>>>>> Table 2
>>>>> Table 3
>>>>> Table 4
>>>>> Table 5
>>>>> Table 6
>>>>> Table 7 -->
>>>>> 
>>>>> 
>>>>> 7) <!-- [rfced] Section 4.1:  Should the section title be "Application
>>>>> Identifier Bit Masks" or "Application Identifier Bit Mask Types"?
>>>>> We ask because we see "two bit masks" in the sentence that follows,
>>>>> as well as "zero-length Application Identifier Bit Masks" elsewhere.
>>>>> 
>>>> [LES:] Title is fine as is.
>>>> Application Identifier Bit Masks is the name of the set of fields (SABM
>> Length, UDABM Length, SABM bit mask, UDABM bit mask) which are encoded
>> in the ASLA sub-TLV.
>>>> 
>>>>> Original:
>>>>> 4.1.  Application Identifier Bit Mask -->
>>>>> 
>>>>> 
>>>>> 8) <!-- [rfced] Sections 4.2 and 4.3:  We cannot tell whether "SABM" in
>>>>> these sentences refers to the SABM field or the SABM Length field.
>>>>> Will these sentences be clear to readers, or should "SABM or UDABM
>>>>> Length" be "SABM Length or UDABM Length"?
>>>>> 
>>>> [LES:] It is probably clearer to say "SABM Length or UDABM length"
>>>> 
>>>>> Original:
>>>>> If the SABM or UDABM Length in the Application Identifier Bit Mask is
>>>>> greater than 8, the entire sub-TLV MUST be ignored.
>>>>> 
>>>>> When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
>>>>> applications specified in the bit mask MUST use the link attribute
>>>>> advertisements in the sub-TLV.
>>>>> ...
>>>>> If the SABM or UDABM Length in the Application Identifier Bit Mask is
>>>>> greater than 8, the entire sub-TLV MUST be ignored.
>>>>> 
>>>>> When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
>>>>> applications specified in the bit mask MUST use SRLG advertisements
>>>>> in the Application-Specific SRLG TLV. -->
>>>>> 
>>>>> 
>>>>> 9) <!-- [rfced] Section 4.2:  For ease of the reader, should "LSP" be
>>>>> defined as "Label-Switched Path" per RFC 3209 or "Link State Protocol
>>>>> Data Unit" per RFC 5305?
>>>> 
>>>> [LES:] "Link State Protocol Data Unit"
>>>> 
>>>>> 
>>>>> Original:
>>>>> In cases where conflicting values for the same
>>>>> application/attribute/link are advertised, the first advertisement
>>>>> received in the lowest-numbered LSP MUST be used, and subsequent
>>>>> advertisements of the same attribute MUST be ignored. -->
>>>>> 
>>>>> 
>>>>> 10) <!-- [rfced] Section 4.3:  As it appears that "a single TLV" refers
>>>>> to the new Application-Specific SRLG TLV and not to some other type
>>>>> of TLV, we changed "a single TLV" to "this new single TLV" here.
>>>>> If this is incorrect, please provide clarifying text.
>>>> 
>>>> [LES:] This is fine.
>>>> 
>>>>> 
>>>>> Original (the previous sentence is included for context):
>>>>> A new TLV is defined to advertise application-specific SRLGs for a
>>>>> given link.  Although similar in functionality to TLV 138 [RFC5307]
>>>>> and TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6,
>>>>> and unnumbered identifiers for a link.
>>>>> 
>>>>> Currently:
>>>>> Although similar in functionality to TLV 138 [RFC5307]
>>>>> and TLV 139 [RFC6119], this new single TLV provides support for IPv4,
>>>>> IPv6, and unnumbered identifiers for a link. -->
>>>>> 
>>>>> 
>>>>> 11) <!-- [rfced] Sections 5 and 6:  We changed lowercased instances of
>>>>> "application-specific link attribute(s)" to "ASLA(s)" per the
>>>>> expansion provided in Section 4.  Please review, and let us know any
>>>>> objections. -->
>>>>> 
>>>> [LES:] No objection
>>>> 
>>>>> 
>>>>> 12) <!-- [rfced] Sections 5 and subsequent:  The following instances of
>>>>> "LFA" in these sentences read oddly.  Should they be plural or
>>>>> perhaps "LFA Policy"?
>>>>> 
>>>> [LES:] "LFA" is correct. This refers to the application types defined in Section
>> 4.1
>>>> 
>>>>> Original:
>>>>> In the case of LFA, the advertisement of application-specific link
>>>>> attributes does not indicate enablement of LFA on that link.
>>>>> ...
>>>>> *  The application is SR Policy or LFA, and RSVP-TE is not deployed
>>>>>  anywhere in the network.
>>>>> 
>>>>> *  The application is SR Policy or LFA, RSVP-TE is deployed in the
>>>>>  network, and both the set of links on which SR Policy and/or LFA
>>>>>  advertisements are required and the attribute values used by SR
>>>>>  Policy and/or LFA on all such links are fully congruent with the
>>>>>  links and attribute values used by RSVP-TE.
>>>>> 
>>>>> Under the conditions defined above, implementations that support the
>>>>> extensions defined in this document have the choice of using legacy
>>>>> advertisements or application-specific advertisements in support of
>>>>> SR Policy and/or LFA.
>>>>> ...
>>>>> Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the
>>>>> legacy advertisements listed in Section 3. -->
>>>>> 
>>>>> 
>>>>> 13) <!-- [rfced] Section 5:  Per previous text in this document, we
>>>>> changed "advertisement of link attribute advertisements" to
>>>>> "advertisement of link attributes".  If this is incorrect, please
>>>>> provide alternative text.
>>>>> 
>>>> [LES:] This is fine.
>>>> 
>>>>> Original:
>>>>> In the presence of
>>>>> an application where the advertisement of link attribute
>>>>> advertisements is used to infer the enablement of an application on
>>>>> that link (e.g., RSVP-TE), the absence of the application identifier
>>>>> leaves ambiguous whether that application is enabled on such a link.
>>>>> 
>>>>> Currently:
>>>>> In the presence of
>>>>> an application where the advertisement of link attributes is used to
>>>>> infer the enablement of an application on that link (e.g., RSVP-TE),
>>>>> the absence of the application identifier leaves ambiguous whether
>>>>> that application is enabled on such a link. -->
>>>>> 
>>>>> 
>>>>> 14) <!-- [rfced] Section 9:
>>>>> 
>>>>> a) We could not locate the discussion in question via the information
>>>>> in the current text.  Searching by thread on
>>>>> <https://mailarchive.ietf.org/arch/browse/lsr/> for
>>>>> "Proposed Errata for RFCs 8919/8920" directed us to
>>>>> <https://mailarchive.ietf.org/arch/>, which provides an
>>>>> "Enter list name or search query..." box, which did not yield the
>>>>> desired information.
>>>>> 
>>>> [LES:] The removal of the URL was done based on feedback during IESG
>> review. IT was commented that any such URL might not be valid indefinitely.
>>>> 
>>>> When I put "Proposed Errata for RFCs 8919/8920" into the search bar at
>> https://mailarchive.ietf.org/arch/browse/lsr/ I do find the relevant thread.
>>>> 
>>>> 
>>>> 
>>>>> However, when looking at <https://www.rfc-editor.org/errata/eid6630>
>>>>> (the erratum page for RFC 8919), we found
>>>>> 
>> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/
>>>>>> .
>>>>> Would pointing to this link instead of 'the thread "Proposed Errata
>>>>> for RFCs 8919/8920"' be acceptable?  If not, please provide a URL
>>>>> that can be listed as a good starting point for readers interested in
>>>>> this information.
>>>>> 
>>>>> Original (the previous sentence is included for context):
>>>>> Discussion within the LSR WG indicated that there was confusion
>>>>> regarding the use of ASLA advertisements that had a zero length SABM/
>>>>> UDABM.  The discussion can be seen by searching the LSR WG mailing
>>>>> list archives for the thread "Proposed Errata for RFCs 8919/8920"
>>>>> starting on 15 June 2021.
>>>>> 
>>>>> Possibly:
>>>>> Discussion within the LSR WG indicated that there was confusion
>>>>> regarding the use of ASLA advertisements that had a zero-length SABM/
>>>>> UDABM.  The discussion can be seen on
>>>>> 
>>>>> 
>> <https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/
>>>>>> .
>>>>> 
>>>>> b) We see that the "NEW" text for Section 4.2 was applied per
>>>>> <https://www.rfc-editor.org/errata/eid6630> but the "NEW" text for
>>>>> Section 6.2 was not.  Is this as desired (i.e., does "subject to the
>>>>> restrictions specified in Section 4.2" in the first paragraph of
>>>>> Section 6.2 handle the erratum information adequately?)? -->
>>>>> 
>>>>> 
>>>>> 15) <!-- [rfced] We added RFC 8919 to the list of Normative References.
>>>>> Please let us know if it should be an Informative Reference instead.
>>>> 
>>>> [LES:] Fine as a normative reference.
>>>> 
>>>>> -->
>>>>> 
>>>>> 
>>>>> 16) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>>> online Style Guide at
>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>>> and let us know if any changes are needed.
>>>>> 
>>>>> Note that our script did not flag any words in particular, but this
>>>>> should still be reviewed as a best practice. -->
>>>> 
>>>> [LES:] No changes are needed that I can see.
>>>> 
>>>>> 
>>>>> 
>>>>> 17) <!-- [rfced] The following term appears to be used inconsistently in
>>>>> this document.  Please let us know which form is preferred.
>>>>> 
>>>> [LES:] Please use lower case "legacy".
>>>> 
>>>>  Les
>>>> 
>>>>> Legacy sub-TLV / legacy sub-TLV (text in Section 4.2) -->
>>>>> 
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> RFC Editor/lb/ap
>>> 
>>> 
>>>> On Sep 25, 2023, at 3:10 PM, Les Ginsberg (ginsberg)
>> <ginsberg=[e-mail]> wrote:
>>>> 
>>>> Folks -
>>>> 
>>>> I am fine with the changes introduced with the following exceptions:
>>>> 
>>>> 1)Section 6.3.3
>>>> 
>>>> "while continuing to use legacy advertisements"
>>>> 
>>>> Please change this to
>>>> 
>>>> "while continuing to advertise legacy advertisements"
>>>> 
>>>> The point is to indicate that both forms need to be advertised(sic).
>>>> The last sentence in the paragraph clearly states what is used.
>>>> 
>>>> 2)Section 7.2
>>>> 
>>>> You have changed column #2 to be "Name" - but the corresponding registry
>> uses the original term "Description".
>>>> Please revert this change.
>>>> 
>>>> 3)Section 7.5
>>>> 
>>>> You changed the title to "IS-IS Sub-TLVs for Application-Specific SRLG TLV
>> Registry (for TLV 238)".
>>>> 
>>>> This does not match the title in the registry:
>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-
>> codepoints.xhtml#tlv-238
>>>> 
>>>> "IS-IS Sub-TLVs for Application-Specific SRLG TLV"
>>>> 
>>>>  Les
>>>> 
>>>>> -----Original Message-----
>>>>> From: [e-mail] <[e-mail]>
>>>>> Sent: Monday, September 11, 2023 2:57 PM
>>>>> To: Les Ginsberg (ginsberg) <[e-mail]>; Peter Psenak
>> (ppsenak)
>>>>> <[e-mail]>; [e-mail];
>> [e-mail];
>>>>> [e-mail]
>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail]; [e-mail]
>>>>> Subject: AUTH48: RFC-to-be 9479 <draft-ietf-lsr-rfc8919bis-04> for your
>>>>> review
>>>>> 
>>>>> *****IMPORTANT*****
>>>>> 
>>>>> Updated 2023/09/11
>>>>> 
>>>>> RFC Author(s):
>>>>> --------------
>>>>> 
>>>>> Instructions for Completing AUTH48
>>>>> 
>>>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>>>> approved by you and all coauthors, it will be published as an RFC.
>>>>> If an author is no longer available, there are several remedies
>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>> 
>>>>> You and you coauthors are responsible for engaging other parties
>>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>>> your approval.
>>>>> 
>>>>> Planning your review
>>>>> ---------------------
>>>>> 
>>>>> Please review the following aspects of your document:
>>>>> 
>>>>> *  RFC Editor questions
>>>>> 
>>>>> Please review and resolve any questions raised by the RFC Editor
>>>>> that have been included in the XML file as comments marked as
>>>>> follows:
>>>>> 
>>>>> <!-- [rfced] ... -->
>>>>> 
>>>>> These questions will also be sent in a subsequent email.
>>>>> 
>>>>> *  Changes submitted by coauthors
>>>>> 
>>>>> Please ensure that you review any changes submitted by your
>>>>> coauthors.  We assume that if you do not speak up that you
>>>>> agree to changes submitted by your coauthors.
>>>>> 
>>>>> *  Content
>>>>> 
>>>>> Please review the full content of the document, as this cannot
>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>> - IANA considerations updates (if applicable)
>>>>> - contact information
>>>>> - references
>>>>> 
>>>>> *  Copyright notices and legends
>>>>> 
>>>>> Please review the copyright notice and legends as defined in
>>>>> RFC 5378 and the Trust Legal Provisions
>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>> 
>>>>> *  Semantic markup
>>>>> 
>>>>> Please review the markup in the XML file to ensure that elements of
>>>>> content are correctly tagged.  For example, ensure that <sourcecode>
>>>>> and <artwork> are set correctly.  See details at
>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>> 
>>>>> *  Formatted output
>>>>> 
>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>> formatted output, as generated from the markup in the XML file, is
>>>>> reasonable.  Please note that the TXT will have formatting
>>>>> limitations compared to the PDF and HTML.
>>>>> 
>>>>> 
>>>>> Submitting changes
>>>>> ------------------
>>>>> 
>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>>>>> the parties CCed on this message need to see your changes. The parties
>>>>> include:
>>>>> 
>>>>> *  your coauthors
>>>>> 
>>>>> *  [e-mail] (the RPC team)
>>>>> 
>>>>> *  other document participants, depending on the stream (e.g.,
>>>>>    IETF Stream participants are your working group chairs, the
>>>>>    responsible ADs, and the document shepherd).
>>>>> 
>>>>> *  [e-mail], which is a new archival mailing list
>>>>>    to preserve AUTH48 conversations; it is not an active discussion
>>>>>    list:
>>>>> 
>>>>>   *  More info:
>>>>>      https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-
>>>>> 4Q9l2USxIAe6P8O4Zc
>>>>> 
>>>>>   *  The archive itself:
>>>>>      https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>> 
>>>>>   *  Note: If only absolutely necessary, you may temporarily opt out
>>>>>      of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>      If needed, please add a note at the top of the message that you
>>>>>      have dropped the address. When the discussion is concluded,
>>>>>      [e-mail] will be re-added to the CC list and
>>>>>      its addition will be noted at the top of the message.
>>>>> 
>>>>> You may submit your changes in one of two ways:
>>>>> 
>>>>> An update to the provided XML file
>>>>> — OR —
>>>>> An explicit list of changes in this format
>>>>> 
>>>>> Section # (or indicate Global)
>>>>> 
>>>>> OLD:
>>>>> old text
>>>>> 
>>>>> NEW:
>>>>> new text
>>>>> 
>>>>> You do not need to reply with both an updated XML file and an explicit
>>>>> list of changes, as either form is sufficient.
>>>>> 
>>>>> We will ask a stream manager to review and approve any changes that
>> seem
>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text,
>>>>> and technical changes.  Information about stream managers can be found
>> in
>>>>> the FAQ.  Editorial changes do not require approval from a stream
>> manager.
>>>>> 
>>>>> 
>>>>> Approving for publication
>>>>> --------------------------
>>>>> 
>>>>> To approve your RFC for publication, please reply to this email stating
>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>>> as all the parties CCed on this message need to see your approval.
>>>>> 
>>>>> 
>>>>> Files
>>>>> -----
>>>>> 
>>>>> The files are available here:
>>>>> https://www.rfc-editor.org/authors/rfc9479.xml
>>>>> https://www.rfc-editor.org/authors/rfc9479.html
>>>>> https://www.rfc-editor.org/authors/rfc9479.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9479.txt
>>>>> 
>>>>> Diff file of the text:
>>>>> https://www.rfc-editor.org/authors/rfc9479-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9479-rfcdiff.html (side by side)
>>>>> 
>>>>> Diff of the XML:
>>>>> https://www.rfc-editor.org/authors/rfc9479-xmldiff1.html
>>>>> 
>>>>> 
>>>>> Tracking progress
>>>>> -----------------
>>>>> 
>>>>> The details of the AUTH48 status of your document are here:
>>>>> https://www.rfc-editor.org/auth48/rfc9479
>>>>> 
>>>>> Please let us know if you have any questions.
>>>>> 
>>>>> Thank you for your cooperation,
>>>>> 
>>>>> RFC Editor
>>>>> 
>>>>> --------------------------------------
>>>>> RFC9479 (draft-ietf-lsr-rfc8919bis-04)
>>>>> 
>>>>> Title            : IS-IS Application-Specific Link Attributes
>>>>> Author(s)        : L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake
>>>>> WG Chair(s)      : Acee Lindem, Christian Hopps
>>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>>>>> 
>>>> 
>>> 
>