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

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

Folks -

I have yet to review the updated text. I will send another email once I have completed that.

As regards your followup question regarding the "terms", please see my responses inline.


> -----Original Message-----
> From: Alanna Paloma <[e-mail]>
> Sent: Friday, January 6, 2023 12:48 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; lsr-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9346 <draft-ietf-lsr-isis-rfc5316bis-07> for
> your review
> 
> 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.

[LES:] As to whether "TLV" or "sub-TLV" should appear, I think this depends on context. In the text, the inclusion of TLV or sub-TLV is useful. But in the IANA sub-sections and the IANA registries the use of "TLV" or "sub-TLV" is redundant since the section title/registry name clearly indicates that what is being defined is a TLV or sub-TLV.
(Yes - I note that some names (unrelated to this draft) in the IANA registries include "TLV" - I think that is beyond the scope of what we want to address here.)

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

[LES:] Inter-AS Reachability Information

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

[LES:] Remote AS Number

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

[LES:] IPv4 Remote ASBR Identifier

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

[LES:] IPv6 Remote ASBR Identifier

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

[LES:] IPv6 Local ASBR Identifier

   Les

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