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

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

I have reviewed the latest version of the document.
I believe all the discussed changes have been made correctly and I have no additional comments.

Consider this my approval of the content for publication.

Thank you for your diligence in responding to all my comments.

   Les



> -----Original Message-----
> From: Alanna Paloma <[e-mail]>
> Sent: Wednesday, January 11, 2023 4:06 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: [AD] Re: AUTH48: RFC-to-be 9346 <draft-ietf-lsr-isis-rfc5316bis-07>
> for your review
> 
> Hi Les and *John,
> 
> *John (AD) - This is a friendly reminder that we await your approval 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 reply. We have updated the files accordingly.
> 
> We will await any further changes you have, as well as approvals from each
> author and *John. Once we have received all approvals, we will ask IANA to
> update their registries accordingly. After the IANA updates are complete, we
> will move forward with the publication process.
> 
> 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)
> https://www.rfc-editor.org/authors/rfc9346-lastdiff.html (last version to this
> one)
> https://www.rfc-editor.org/authors/rfc9346-lastrfcdiff.html (rfcdiff between
> last version and this)
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9346
> 
> Best regards,
> RFC Editor/ap
> 
> > On Jan 8, 2023, at 11:10 PM, Les Ginsberg (ginsberg) <[e-mail]>
> wrote:
> >
> > 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