Re: [auth48] AUTH48: RFC-to-be 9346 <draft-ietf-lsr-isis-rfc5316bis-07> for your review

[Alanna Paloma <[e-mail]>]

Hi Les and *John,

*John - As the AD, please review and approve of the added text in Section 3.4.4 in the following diff file:
https://www.rfc-editor.org/authors/rfc9346-auth48diff.html

Thank you for your reply.  We have updated as requested. We have a follow-up question regarding the query below. 

>> 10) <!-- [rfced] Questions about names of TLVs and Sub-TLVs
>> 
>> a) The following TLVs and sub-TLVs are defined in this document (some were
>> originally defined in RFC 5316). We note some inconsistencies in the names.
>> We
>> listed the form used in the IANA section followed by the form(s) appearing in
>> general text. Please review and let us know which form you prefer. Note
>> that
>> the capitalized form seems more common when looking through the TLVs
>> listed at
>> https://www.iana.org/assignments/isis-tlv-codepoints.
>> 
>> If any changes are made that affect the registries at
>> https://www.iana.org/assignments/isis-tlv-codepoints, we will ask IANA to
>> update the registries accordingly.
> 
> [LES:]It is desirable to have consistency between what is used in the text and what is used in the IANA registries. The only caveat seems to be that when a TLV/sub-TLV name appears as the title of a section there seems to be a practice of capitalizing even when a particular word is NOT capitalized when the name is used in the body of the document. This seems to include the term “Sub-TLV”/”sub-TLV” as well.
> If you are willing to insure that the document and the IANA registry are fully consistent then I prefer the capitalized forms for all words.

We note that you prefer the terms below  to be capitalized, but as there is a variance in what appears in the IANA registrations and what appears in the text, please let us know which form is preferable so that these can be made consistent. Should “TLV”/"Sub-TLV” appear after the terms? Whichever form is chosen, we will capitalize it and make it consistent between the text and the IANA registries. 

inter-AS reachability information - IANA Considerations section                      
inter-AS reachability TLV                                                            
Inter-AS Reachability TLV                                                            

remote AS number - IANA Considerations section and table in Section 3.2              
Remote AS Number sub-TLV                                                             
remote AS number sub-TLV                                                             

IPv4 remote ASBR identifier - IANA Considerations section and table in Section 3.2   
IPv4 Remote ASBR ID Sub-TLV                                                          
IPv4 remote ASBR ID sub-TLV                                                          

IPv6 remote ASBR identifier - IANA Considerations section and table in Section 3.2   
IPv6 Remote ASBR ID Sub-TLV                                                          
IPv6 remote ASBR ID sub-TLV                                                          

IPv6 local ASBR identifier - IANA Considerations section and table in Section 3.2    
IPv6 Local ASBR ID sub-TLV                                                           
IPv6 Local ASBR identifier sub-TLV                                                   

The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9346.xml
https://www.rfc-editor.org/authors/rfc9346.txt
https://www.rfc-editor.org/authors/rfc9346.html
https://www.rfc-editor.org/authors/rfc9346.pdf

The relevant diff files have been posted here:
https://www.rfc-editor.org/authors/rfc9346-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9346-auth48diff.html (AUTH48 changes)

Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.

We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.

For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9346

Thank you,
RFC Editor/ap

> On Jan 4, 2023, at 1:37 PM, Les Ginsberg (ginsberg) <ginsberg=[e-mail]> wrote:
> 
> Folks –
>  
> Please find responses to your questions inline.
>  
>  
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Friday, December 16, 2022 12:39 PM
> > To: [e-mail]; Les Ginsberg (ginsberg)
> > <[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 9346 <draft-ietf-lsr-isis-rfc5316bis-07> 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] While we understand that RFC 5316 was published
> > with some of the text we are questioning below, the questions and
> > edits are aimed at making the text as correct and useful to the reader
> > as possible.  Please review carefully.
> > 
> > In addition, this document is in the current RFC format (a major change
> > was made in 2019), so various updates have been made in the source file.
> > Details are here: https://www.rfc-editor.org/pubprocess/how-we-update.
> > -->
> > 
> > 
> > 2) <!-- [rfced] Would updating the document title as follows be an
> > improvement?
> > The current title is the same as the title of RFC 5316, but we question
> > if the suggestion below might improve readability.
> > 
> > Original:
> >   IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and
> >   GMPLS Traffic Engineering
> > 
> > Perhaps:
> >   IS-IS Extensions in Support of MPLS and
> >   GMPLS Traffic Engineering for Multiple Autonomous Systems
> > -->
> > 
> [LES:] I prefer to use the existing title. It is consistent with RFC 4216.
>  
> > 
> > 3) <!-- [rfced] We have several questions about the sentences below:
> > 
> > - Should "three" in these sentences read "four" as this document
> > defines the four sub-TLVs listed in the table in Section 6.1?
> > 
> [LES:] Yes – thanx for correcting this.
>  
> > - Should "neighboring AS number" in the second sentence read "remote AS
> > number"?
>  
> [LES:] There are extensive uses of both “neighbor” and “remote” throughout the document. It isn’t clear to me that we have a clear definition of when to use “remote” and when to use “neighbor”.
> Changing the text in this one case does not add any clarity or value – so I prefer to leave the text as it is.
>  
> > 
> > - Should "local ASBR ID" (or the capitalized "Local ASBR ID") be added in
> > addition to "remote AS number and remote ASBR ID"?
>  
> [LES:] The correct text to add would be “IPv6 Local ASBR ID”.
>  
> > 
> > Original:
> >    In this document, a new TLV, which is referred to as the inter-AS
> >    reachability TLV, is defined to advertise inter-AS TE information,
> >    and three new sub-TLVs are defined for inclusion in the inter-AS
> >    reachability TLV to carry the information about the remote AS number
> >    and remote ASBR ID.
> >    ...
> >    Three new sub-TLVs are also defined for inclusion in the
> >    inter-AS reachability TLV to carry the information about the
> >    neighboring AS number and the remote ASBR ID of an inter-AS link.
> > 
> > Perhaps:
> >    In this document, the inter-AS
> >    reachability TLV is defined to advertise inter-AS TE information,
> >    and four sub-TLVs are defined for inclusion in the inter-AS
> >    reachability TLV to carry the information about the remote AS number,
> >    remote ASBR ID, and local ASBR ID.
> >    ...
> >    Three sub-TLVs are also defined for inclusion in the
> >    inter-AS reachability TLV to carry the information about the
> >    neighboring AS number, the remote ASBR ID, and local ASBR ID  of an inter-
> > AS link.
> > -->
> > 
> > 
> > 4) <!-- [rfced] Although this sentence appeared in RFC 5316, would it be
> > helpful
> > to update in this document to avoid using two colons, which may be
> > confusing to readers?
> > 
> > Original:
> >    If an inter-AS TE LSP is planned to be established from R1 to R12,
> >    the traversed domains are assumed to be selected: AS1->AS2->AS3, and
> >    the PCE chain is: PCE1->PCE2->PCE3.
> > 
> > Perhaps:
> >    If an inter-AS TE LSP is planned to be established from R1 to R12,
> >    the traversed domains are assumed to be selected (AS1->AS2->AS3), and
> >    the PCE chain is PCE1->PCE2->PCE3.
> > 
>  
> [LES:] The above change is preferred by me.
>  
> > Or:
> >    If an inter-AS TE LSP is planned to be established from R1 to R12,
> >    the traversed domains are assumed to be selected: AS1->AS2->AS3.
> >    The PCE chain is PCE1->PCE2->PCE3.
> > -->
> > 
> > 
> > 5) <!-- [rfced] FYI - We applied consistent capitalization for the names of the
> > fields in the figure in Section 3.2. In the original, "Router ID" and
> > "Flags" were capitalized; we also capitalized "default metric", "sub-TLVs
> > length", and "sub-TLVs".
> > -->
> [LES:] This is fine with me.
> > 
> > 
> > 6) <!-- [rfced] The text in Section 3.2 refers to the S bit and D bit as
> > "flooding-scope bit (S bit)" and "up/down bit (D bit)", respectively.
> > Would it be helpful to include these in the definitions that appear
> > immediately after the figure? In addition, would it be helpful to
> > capitalize the names of these bits, i.e., "Flooding Scope bit" and
> > "Up/Down bit"? If so, we will also remove the hyphen from "flooding-scope
> > bit".
> > 
> [LES:] I do not see the need to do so. There are no additional uses of the terms in the document.
>  
> > Original:
> >    S bit: If the S bit is set(1), the Inter-AS Reachability TLV
> >    MUST be flooded across the entire routing domain.  If the S bit is
> >    not set(0), the TLV MUST NOT be leaked between levels.  This bit MUST
> >    NOT be altered during the TLV leaking.
> > 
> >    D bit: When the Inter-AS Reachability TLV is leaked from
> >    Level 2 (L2) to Level 1 (L1), the D bit MUST be set.  Otherwise, this
> >    bit MUST be clear.  Inter-AS Reachability TLVs with the D bit set
> >    MUST NOT be leaked from Level 1 to Level 2. This is to prevent TLV
> >    looping.
> > 
> > Perhaps:
> >    S bit (Flooding Scope bit):  If the S bit is set(1), the inter-AS
> >       reachability TLV MUST be
> >       flooded across the entire routing domain.  If the S bit is not
> >       set(0), the TLV MUST NOT be leaked between levels.  This bit MUST
> >       NOT be altered during the TLV leaking.
> > 
> >    D bit (Up/Down bit):  When the inter-AS reachability TLV is leaked from
> > Level 2
> >       (L2) to Level 1 (L1), the D bit MUST be set.  Otherwise, this bit
> >       MUST be clear.  Inter-AS reachability TLVs with the D bit set MUST
> >       NOT be leaked from Level 1 to Level 2.  This is to prevent TLV
> >       looping.
> > -->
> > 
> > 
> > 7) <!-- [rfced] Please review this sentence for correctness. We do not see a
> > "control information" field in the figure in Section 3.2 or elsewhere in
> > the document. Should this be "Flags" field instead?
> > 
> [LES:] I do not see a reason to change the text. One form seems just as clear as the other.
>  
> > Original:
> >    Compared to the extended reachability TLV which is defined in
> >    [RFC5305], the inter-AS reachability TLV replaces the "7 octets of
> >    System ID and Pseudonode Number" field with a "4 octets of Router ID"
> >    field and introduces an extra "control information" field, which
> >    consists of a flooding-scope bit (S bit), an up/down bit (D bit), and
> >    6 reserved bits.
> > 
> > Perhaps:
> >    Compared to the extended IS reachability TLV, which is defined in
> >    [RFC5305], the inter-AS reachability TLV has a 4-octet Router ID field rather
> >    than 7 octets of System ID and Pseudonode Number. In addition,
> >    the inter-AS reachability TLV contains a Flags field
> >    consisting of a flooding-scope bit (S bit), an up/down bit (D bit), and
> >    6 reserved bits.
> > -->
> > 
> > 
> > 8) <!-- [rfced] We note that Sections 3.4.1, 3.4.2, and 3.4.3 include an
> > introductory paragraph about the purpose of the sub-TLV being defined in
> > that subsection. Section 3.4.4 does not include a paragraph like
> > this. Please review and let us know if any updates are needed.
> > 
> > Current introductory paragraph in Section 3.4.1 (similar paragraphs appear in
> > Section 3.4.2 and 3.4.3):
> >    The remote AS number sub-TLV is defined for inclusion in the inter-AS
> >    reachability TLV when advertising inter-AS links.  The remote AS
> >    number sub-TLV specifies the AS number of the neighboring AS to which
> >    the advertised link connects.
> > -->
> > 
> [LES:] I agree. For consistency please add the following introductory paragraph:
>  
> “The IPv6 Local ASBR ID sub-TLV is defined for inclusion in the
>    inter-AS reachability TLV when advertising inter-AS links.  The IPv6
>    Local ASBR ID sub-TLV specifies the IPv6 identifier of the remote
>    ASBR to which the advertised inter-AS link connects.  The value
>    advertised is selected as defined in Section 3.1.”
>  
> You should then remove the redundant text “The value advertised is selected as defined in Section 3.1.” which follows the diagram.
>  
> > 
> > 9) <!-- [rfced] The rulers seemed to be misaligned in the artwork depicting
> > sub-TLVs in Sections 3.5.1 and 3.5.2. We adjusted so that the numbers on
> > the top line are aligned over the zeroes on the second line. Please review.
> > -->
>  
> [LES:]Looks good. Thanx.
>  
> > 
> > 
> > 10) <!-- [rfced] Questions about names of TLVs and Sub-TLVs
> > 
> > a) The following TLVs and sub-TLVs are defined in this document (some were
> > originally defined in RFC 5316). We note some inconsistencies in the names.
> > We
> > listed the form used in the IANA section followed by the form(s) appearing in
> > general text. Please review and let us know which form you prefer. Note
> > that
> > the capitalized form seems more common when looking through the TLVs
> > listed at
> > https://www.iana.org/assignments/isis-tlv-codepoints.
> > 
> > If any changes are made that affect the registries at
> > https://www.iana.org/assignments/isis-tlv-codepoints, we will ask IANA to
> > update the registries accordingly.
>  
> [LES:]It is desirable to have consistency between what is used in the text and what is used in the IANA registries. The only caveat seems to be that when a TLV/sub-TLV name appears as the title of a section there seems to be a practice of capitalizing even when a particular word is NOT capitalized when the name is used in the body of the document. This seems to include the term “Sub-TLV”/”sub-TLV” as well.
> If you are willing to insure that the document and the IANA registry are fully consistent then I prefer the capitalized forms for all words.
>  
> > 
> > inter-AS reachability information - IANA Considerations section
> > inter-AS reachability TLV
> > Inter-AS Reachability TLV
> > 
> > remote AS number - IANA Considerations section and table in Section 3.2
> > Remote AS Number sub-TLV
> > remote AS number sub-TLV
> > 
> > IPv4 remote ASBR identifier - IANA Considerations section and table in
> > Section 3.2
> > IPv4 Remote ASBR ID Sub-TLV
> > IPv4 remote ASBR ID sub-TLV
> > 
> > IPv6 remote ASBR identifier - IANA Considerations section and table in
> > Section 3.2
> > IPv6 Remote ASBR ID Sub-TLV
> > IPv6 remote ASBR ID sub-TLV
> > 
> > IPv6 local ASBR identifier - IANA Considerations section and table in Section
> > 3.2
> > IPv6 Local ASBR ID sub-TLV
> > IPv6 Local ASBR identifier sub-TLV
> > 
> > 
> > b) FYI - We updated "IPv4 TE Router sub-TLV" and "IPv6 Router ID sub-TLV" in
> > these sentences to read "IPv4 TE Router ID sub-TLV" and "IPv6 TE Router ID
> > sub-TLV" (with "ID" after "Router"), respectively.
> > 
> [LES:]Looks good. Thanx.
>  
> > Original:
> >    If the ASBR does not have an IPv6 TE
> >    Router ID, the IPv4 TE Router sub-TLV MUST be included instead.
> >    ...
> >    If the ASBR does not have an IPv4 TE
> >    Router ID, the IPv6 TE Router sub-TLV MUST be included instead.
> > 
> > 
> > c) FYI - We reviewed the names of the following TLVs, which are mentioned
> > in but not
> > defined by this document. We made updates as indicated below.
> > 
> > IS-IS router capability TLV
> > IS-IS Router Capability TLV
> > IS-IS Router CAPABILITY TLV
> >    Note: We updated to "IS-IS Router CAPABILITY TLV" per RFC 7981 and the
> > entry
> >          in the "IS-IS Top-Level TLV Codepoints" registry at
> >          https://www.iana.org/assignments/isis-tlv-codepoints.
> > 
> > extended IS reachability TLV
> > extended reachability TLV
> >    Note: We used "extended IS reachability TLV" per RFC 5305.
> > 
> > traffic engineering router ID TLV
> > Traffic Engineering router ID TLV
> > Traffic Engineering Router ID TLV
> > TE Router ID TLV
> >    Note: We used "Traffic Engineering router ID TLV" per RFC 5305.
> > 
> > IPv6 Intf. Addr TLV
> >    Note: We updated to "IPv6 Interface Address TLV" per RFC 5308.
> > 
> > IPv6 TE Router ID TLV
> >    Note: No change; this form is correct per RFC 6119.
> > 
> > GENINFO TLV
> >    Note: No change; this form is correct per RFC RFC 6823.
> > 
> [LES:]Please be consistent with what is used in the IANA Registry.
> The RFC 5305 definition of “Traffic Engineering router ID TLV” is an unfortunate case in that it uses lower case “router” whereas all other “Router ID” code points use upper case “Router”.
> (Search for case insensitive “router ID” in the TLV Codepoints registry and you will see what I mean.)
> It would be better if RFC 5305/TLV 134 also used “Router ID”, but this represents a change to RFC 5305 as well as the Codepoint Registry. I don’t know if you want to consider this in scope for this work.
> Also not sure if this would require an “editorial errata” to be filed against RFC 5305.
>  
> I leave this to your judgment, but let’s be sure the text in this document is consistent with the IANA registry in all cases.
>  
> > 
> > d) Please review "Traffic Engineering Router ID" here. Should this read either
> > "Traffic Engineering router ID TLV" or "TE Router ID"?
> > 
> > Original:
> >    2.  If no Traffic Engineering Router ID is assigned the Router ID
> >    should be identical to an IP Interface Address [RFC1195] advertised
> >    by the originating IS.
> > -->
> > 
> [LES:]Please leave the text unchanged. “Router ID” here is referencing the field in TLV 141 as defined in the diagram in Section 3.2.
>  
> > 
> > 11) <!-- [rfced] Terminology
> > 
> > a) We expanded "PCC" as "Path Computation Client". Please
> > let us know of any objections.
> > 
> [LES:]Change accepted.
>  
> > Original:
> >    First, the path computation
> >    request originated from the PCC (R1) is relayed by PCE1 and PCE2
> >    along the PCE chain to PCE3.
> > 
> > Current:
> >    First, the path computation
> >    request originated from the Path Computation Client (PCC) (R1) is
> >    relayed by PCE1 and PCE2 along the PCE chain to PCE3.
> > 
> > 
> > b) Please review instances of "Backward Recursive Path Computation" in this
> > document. Are these okay as is, or should instances be updated to
> > "Backward-Recursive PCE-Based Computation"? We see both "Backward-
> > Recursive
> > PCE-Based Computation" (title) and "backward-recursive path computation"
> > (general text) in RFC 5441.
> > 
> [LES:]I think the current text (corrected by you to include a hyphen) is fine as is.
>  
> > 
> > c) Please confirm that "remote ASBR TE Router ID is correct here. We do not
> > see this elsewhere in the document, though we do see both "remote ASBR
> > ID" and
> > "TE Router ID".
> > 
> > Original:
> >    The information advertised comes from the ASBR's knowledge of the TE
> >    capabilities of the link, the ASBR's knowledge of the current status
> >    and usage of the link, and configuration at the ASBR of the remote AS
> >    number and remote ASBR TE Router ID.
> > 
> [LES:]I think the current text is fine as is. What is being referenced is the “TE Router ID” as discussed in Section 3.1.
>  
> > 
> > d) FYI - We updated "ISIS-TE" to "IS-IS TE" as we see "IS-IS" rather than
> > "ISIS" used in other contexts in the document. In addition, the form "IS-IS
> > TE" seems more common in recent RFCs (e.g., 8570).
> > 
> [LES:] This is correct – thanx for making this change.
>  
> > 
> > e) FYI - We removed "new" in the context of "new TLV" or "new sub-TLV"
> > because
> > some of these were originally defined in RFC 5316 so they are not technically
> > "new".
>  
> [LES:] Change accepted.
>  
> > 
> > 
> > f) Please review instances of "remote AS number" and "remote ASBR ID"
> > (not
> > followed by "sub-TLV") in the following sentences. Should these be
> > capitalized,
> > or is the lowercase okay? We ask because these are capitalized in the figures
> > in Sections 3.4.1, 3.4.2, and 3.4.3. In addition, we see that "TE Router ID"
> > is capitalized in general text (not followed by "TLV" or "sub-TLV").
> > 
>  
> [LES:] I believe this issue gets resolved by the discussion under item “10) <!-- [rfced] Questions about names of TLVs and Sub-TLVs” above.
> ???
>  
> > Original:
> >    In this document, a new TLV, which is referred to as the inter-AS
> >    reachability TLV, is defined to advertise inter-AS TE information,
> >    and three new sub-TLVs are defined for inclusion in the inter-AS
> >    reachability TLV to carry the information about the remote AS number
> >    and remote ASBR ID.
> >    ...
> >    The information advertised comes from the ASBR's knowledge of the TE
> >    capabilities of the link, the ASBR's knowledge of the current status
> >    and usage of the link, and configuration at the ASBR of the remote AS
> >    number and remote ASBR TE Router ID.
> >    ...
> >    Only some essential TE information for the link needs to be
> >    advertised; i.e., the Interface Address, the remote AS number, and
> >    the remote ASBR ID of an inter-AS TE link.
> >    ...
> >    Some of the information included in these new advertisements (e.g.,
> >    the remote AS number and the remote ASBR ID) is obtained manually
> >    from a neighboring administration as part of a commercial
> >    relationship.
> >    ...
> >    For example, if a
> >    different remote AS number is received in a BGP OPEN [RFC4271] from
> >    that locally configured to ISIS-TE, as we describe here, then local
> >    policy SHOULD be applied to determine whether to alert the operator
> >    to a potential mis-configuration or to suppress the IS-IS
> >    advertisement of the inter-AS TE link.
> >    ...
> >    Three new sub-TLVs are also defined for inclusion in the
> >    inter-AS reachability TLV to carry the information about the
> >    neighboring AS number and the remote ASBR ID of an inter-AS link.
> > -->
> > 
> > 
> > 12) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> > Style Guide <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.
> > -->
> > 
> > 
> > Thank you.
>  
> [LES:] Thanx for your diligence. Let me know if you have further questions
>  
>    Les
> > 
> > RFC Editor/ap/rv
> > 
> > 
> > 
> > On Dec 16, 2022, at 12:32 PM, [e-mail] wrote:
> > 
> > *****IMPORTANT*****
> > 
> > Updated 2022/12/16
> > 
> > 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/rfc9346.xml
> >   https://www.rfc-editor.org/authors/rfc9346.html
> >   https://www.rfc-editor.org/authors/rfc9346.pdf
> >   https://www.rfc-editor.org/authors/rfc9346.txt
> > 
> > Diff file of the text:
> >   https://www.rfc-editor.org/authors/rfc9346-diff.html
> >   https://www.rfc-editor.org/authors/rfc9346-rfcdiff.html (side by side)
> > 
> > For your convenience, we have also created an alt-diff file that will
> > allow you to more easily view changes where text has been deleted or
> > moved:
> >   https://www.rfc-editor.org/authors/rfc9346-alt-diff.html
> > 
> > Diff of the XML:
> >   https://www.rfc-editor.org/authors/rfc9346-xmldiff1.html
> > 
> > The following files are provided to facilitate creation of your own
> > diff files of the XML.
> > 
> > Initial XMLv3 created using XMLv2 as input:
> >   https://www.rfc-editor.org/authors/rfc9346.original.v2v3.xml
> > 
> > XMLv3 file that is a best effort to capture v3-related format updates
> > only:
> >   https://www.rfc-editor.org/authors/rfc9346.form.xml
> > 
> > 
> > Tracking progress
> > -----------------
> > 
> > The details of the AUTH48 status of your document are here:
> >   https://www.rfc-editor.org/auth48/rfc9346
> > 
> > Please let us know if you have any questions.
> > 
> > Thank you for your cooperation,
> > 
> > RFC Editor
> > 
> > --------------------------------------
> > RFC9346 (draft-ietf-lsr-isis-rfc5316bis-07)
> > 
> > Title            : IS-IS Extensions in Support of Inter-Autonomous System (AS)
> > MPLS and GMPLS Traffic Engineering
> > Author(s)        : M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong
> > WG Chair(s)      : Acee Lindem, Christian Hopps
> > Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> >