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

[Lynne Bartholomew <[e-mail]>]

Hi, Les.

Thanks for the email.  We have noted your approval (set to 9/27/2023, per your previous email) on the AUTH48 status page:

   https://www.rfc-editor.org/auth48/rfc9479

Thanks again for helping us with AUTH48!

RFC Editor/lb

> On Sep 28, 2023, at 3: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]>; [e-mail]; Peter
>> Psenak (ppsenak) <[e-mail]>; [e-mail];
>> [e-mail]; [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
>> 
>> 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] <[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
>>>>>> 
>>>>> 
>>> 
>