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

[Stefano Previdi <[e-mail]>]

Hi all,

I also approve the publication.

Thanks.
s.

On Fri, Sep 29, 2023, 18:07 Lynne Bartholomew <[e-mail]> wrote:

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