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

[Mach Chen <[e-mail]>]

The latest version looks good to me, consider this my approval of the document for the publication as well.

Best regards,
Mach

> -----Original Message-----
> From: Les Ginsberg (ginsberg) <[e-mail]>
> Sent: Tuesday, January 17, 2023 1:32 PM
> To: Alanna Paloma <[e-mail]>; [e-mail]
> Cc: [e-mail]; Mach Chen <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [AD] Re: AUTH48: RFC-to-be 9346 <draft-ietf-lsr-isis-rfc5316bis-07>
> for your review
> 
> 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