Re: [auth48] [AD] AUTH48: RFC-to-be 9514 <draft-ietf-idr-bgpls-srv6-ext-14> for your review

[Mach Chen <[e-mail]>]

Hi Alanna,

I approve the publication of this document.

Best regards,
Mach

> -----Original Message-----
> From: Alanna Paloma <[e-mail]>
> Sent: Wednesday, November 22, 2023 2:05 AM
> To: [e-mail]; Ketan Talaulikar <[e-mail]>
> Cc: Madison Church <[e-mail]>; [e-mail]; Mach Chen
> <[e-mail]>; [e-mail]; [e-mail];
> Alvaro Retana <[e-mail]>; RFC Editor
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [AD] AUTH48: RFC-to-be 9514 <draft-ietf-idr-bgpls-srv6-ext-14>
> for your review
> 
> Hi Ketan and Bruno,
> 
> Thank you for your replies. Your approvals have been noted on the AUTH48
> status page:
>  https://www.rfc-editor.org/auth48/rfc9514
> 
> Ketan - We have updated the files with your proposed text.
> 
> Updated XML file:
>  https://www.rfc-editor.org/authors/rfc9514.xml
> 
> Updated output files:
>  https://www.rfc-editor.org/authors/rfc9514.txt
>  https://www.rfc-editor.org/authors/rfc9514.pdf
>  https://www.rfc-editor.org/authors/rfc9514.html
> 
> Diff file showing all changes made during AUTH48:
>  https://www.rfc-editor.org/authors/rfc9514-auth48diff.html
> 
> Diff files showing all changes:
>  https://www.rfc-editor.org/authors/rfc9514-diff.html
>  https://www.rfc-editor.org/authors/rfc9514-rfcdiff.html (side-by-side diff)
> https://www.rfc-editor.org/authors/rfc9514-alt-diff.html (diff showing
> changes where text is moved or deleted)
> 
> We will await approvals from Gaurav, Clarence, Mach, Daniel, and the AD
> prior to moving this document forward.
> 
> Best regards,
> RFC Editor/ap
> 
> > On Nov 21, 2023, at 2:12 AM, [e-mail] wrote:
> >
> > Hi Alanna,
> >
> > Thanks for the edits.
> >
> > I approve the document.
> >
> > Thanks,
> > --Bruno
> >
> >
> > From: Ketan Talaulikar <[e-mail]>
> > Sent: Tuesday, November 21, 2023 6:41 AM
> > To: Alanna Paloma <[e-mail]>
> > Cc: Madison Church <[e-mail]>; DECRAENE Bruno INNOV/NET
> > <[e-mail]>; [e-mail];
> [e-mail];
> > [e-mail]; [e-mail]; Alvaro Retana
> > <[e-mail]>; RFC Editor <[e-mail]>;
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: [AD] AUTH48: RFC-to-be 9514
> > <draft-ietf-idr-bgpls-srv6-ext-14> for your review
> >
> > Hi Alanna,
> >
> > After reviewing the full text, I would suggest the following text
> > change
> >
> > OLD:
> > Only undefined flags MUST be set to 0 when originating and ignored on
> receipt.
> >
> > NEW:
> > Undefined flags MUST be set to 0 when originating and ignored on receipt.
> >
> > Along with the above change, please take this as an approval from my side.
> >
> > Thanks,
> > Ketan
> >
> >
> > On Tue, Nov 21, 2023 at 12:43 AM Alanna Paloma <[e-mail]>
> wrote:
> > Hi Ketan,
> >
> > We have updated that text in the files.
> >
> > Updated XML file:
> >   https://www.rfc-editor.org/authors/rfc9514.xml
> >
> > Updated output files:
> >   https://www.rfc-editor.org/authors/rfc9514.txt
> >   https://www.rfc-editor.org/authors/rfc9514.pdf
> >   https://www.rfc-editor.org/authors/rfc9514.html
> >
> > Diff file showing all changes made during AUTH48:
> >   https://www.rfc-editor.org/authors/rfc9514-auth48diff.html
> >
> > Diff files showing all changes:
> >   https://www.rfc-editor.org/authors/rfc9514-diff.html
> >   https://www.rfc-editor.org/authors/rfc9514-rfcdiff.html (side-by-side
> diff)
> >   https://www.rfc-editor.org/authors/rfc9514-alt-diff.html (diff
> > showing changes where text is moved or deleted)
> >
> > Note that it may be necessary for you to refresh your browser to view the
> most recent version.
> >
> > We will await approvals from each author and the AD prior to moving
> forward in the publication process.
> >
> > For the AUTH48 status of this document, please see:
> >  https://www.rfc-editor.org/auth48/rfc9514
> >
> > Thank you,
> > RFC Editor/ap
> >
> > > On Nov 20, 2023, at 9:54 AM, Ketan Talaulikar <[e-mail]>
> wrote:
> > >
> > > Hi Alanna,
> > >
> > > This text works.
> > >
> > > Thanks,
> > > Ketan
> > >
> > >
> > > On Mon, Nov 20, 2023 at 11:16 PM Alanna Paloma <[e-mail]>
> wrote:
> > > Hi Ketan,
> > >
> > > Thank you for clarifying. Does the following text work?
> > >
> > > Perhaps:
> > >  No flags are currently defined for SRv6 SIDs corresponding to BGP
> > > EPE  or for advertisement of SRv6 SIDs using Direct as the Protocol-
> > > ID. Only undefined flags MUST be set to 0 when originating and
> > > ignored on receipt.
> > >
> > > Best regards,
> > > RFC Editor/ap
> > >
> > > > On Nov 17, 2023, at 8:27 PM, Ketan Talaulikar <[e-mail]>
> wrote:
> > > >
> > > > Hi Madison,
> > > >
> > > > Please check inline below.
> > > >
> > > >
> > > > On Sat, Nov 18, 2023 at 4:39 AM Madison Church
> <[e-mail]> wrote:
> > > > Hi Ketan and Bruno,
> > > >
> > > > Thank you both for your replies! We have updated the document
> accordingly. We just have one followup item.
> > > >
> > > > For the following:
> > > > > There is one issue with the changed text for "Flags" field in Section 7.1.
> The following sentence applies only for BGP EPE and Direct:
> > > > >
> > > > > Flags MUST be set to 0 when originated and ignored on receipt.
> > > > >
> > > > > However, the breaking of the sentence could make a reader think as if
> it also applied to OSPF and ISIS. Can this be rephrased for clarity?
> > > >
> > > > Thank you for pointing this out. Is the intent that when flags are
> eventually defined for BGP EPE and Direct, those flags MUST be set to 0 when
> originated and ignored on receipt? Would the following work?
> > > >
> > > > KT> It is actually the other way around. Since no flags are defined for
> BGP EPE and Direct, they must be set to 0 when originating and ignored on
> receipt.  Once some flags are defined, then this (setting to 0 and ignoring on
> receipt) would apply only to the undefined flags alone. I hope that clarifies.
> > > >
> > > > Thanks,
> > > > Ketan
> > > >
> > > >
> > > > Perhaps:
> > > >   No flags are currently defined for SRv6 SIDs corresponding to BGP
> EPE
> > > >   or for advertisement of SRv6 SIDs using Direct as the Protocol-
> > > >   ID, but when defined, the flags MUST be set to 0 when originated and
> ignored on
> > > >   receipt.
> > > >
> > > > Updated XML file:
> > > >    https://www.rfc-editor.org/authors/rfc9514.xml
> > > >
> > > > Updated output files:
> > > >    https://www.rfc-editor.org/authors/rfc9514.txt
> > > >    https://www.rfc-editor.org/authors/rfc9514.pdf
> > > >    https://www.rfc-editor.org/authors/rfc9514.html
> > > >
> > > > Diff file showing all changes made during AUTH48:
> > > >    https://www.rfc-editor.org/authors/rfc9514-auth48diff.html
> > > >
> > > > Diff files showing all changes:
> > > >    https://www.rfc-editor.org/authors/rfc9514-diff.html
> > > >    https://www.rfc-editor.org/authors/rfc9514-rfcdiff.html
> (side-by-side diff)
> > > >    https://www.rfc-editor.org/authors/rfc9514-alt-diff.html (diff
> > > > showing changes where text is moved or deleted)
> > > >
> > > > Note that it may be necessary for you to refresh your browser to view
> the most recent version.
> > > >
> > > > For the AUTH48 status of this document, please see:
> > > >   https://www.rfc-editor.org/auth48/rfc9514
> > > >
> > > > Thank you,
> > > > RFC Editor/mc
> > > >
> > > > > On Nov 17, 2023, at 10:12 AM, Ketan Talaulikar
> <[e-mail]> wrote:
> > > > >
> > > > > Hi Bruno,
> > > > >
> > > > > I agree with your suggestion. I find it more clear.
> > > > >
> > > > > Thanks,
> > > > > Ketan
> > > > >
> > > > >
> > > > > On Fri, Nov 17, 2023 at 9:34 PM <[e-mail]>
> wrote:
> > > > > Hi Madison, Ketan,
> > > > >
> > > > > I'm fine with this document.
> > > > > May be one comment, up to you
> > > > >
> > > > > In section 6
> > > > >
> > > > > OLD:  This document defines the following new Link-State NLRI type
> for SRv6 SID information: SRv6 SID NLRI (6).
> > > > > NEW: This document defines the following new Link-State NLRI type
> for SRv6 SID information: SRv6 SID NLRI (type 6).
> > > > >
> > > > > Motivation: the type number is not otherwise indicated in the
> > > > > rest of the section. I'd have a preference for an explicit
> > > > > mention of "type 6" rather than just "(6)". (I also find easier
> > > > > to be able to find type number by searching for "type" in the
> > > > > document)
> > > > >
> > > > > Thank you
> > > > > Regards,
> > > > > --Bruno
> > > > >
> > > > >
> > > > > Orange Restricted
> > > > >
> > > > > -----Original Message-----
> > > > > From: Madison Church <[e-mail]>
> > > > > Sent: Friday, November 10, 2023 10:59 PM
> > > > > To: Ketan Talaulikar <[e-mail]>;
> > > > > [e-mail];[e-mail]; [e-mail];
> > > > > [e-mail]; DECRAENE Bruno INNOV/NET
> > > > > <[e-mail]>; Alvaro Retana
> > > > > <[e-mail]>
> > > > > Cc: RFC Editor <[e-mail]>; [e-mail];
> > > > > [e-mail]; [e-mail];
> > > > > [e-mail]
> > > > > Subject: Re: [AD] AUTH48: RFC-to-be 9514
> > > > > <draft-ietf-idr-bgpls-srv6-ext-14> for your review
> > > > >
> > > > > Hi Ketan,
> > > > >
> > > > > Thank you for your reply! We have updated the document accordingly
> and all of our questions have been addressed.
> > > > >
> > > > > Please review the document carefully to ensure satisfaction as we do
> not make changes once it has been published as an RFC. Contact us with any
> further updates or with your approval of the document in its current form.
> We will await approvals from each author prior to moving forward in the
> publication process.
> > > > >
> > > > > Updated XML file:
> > > > >    https://www.rfc-editor.org/authors/rfc9514.xml
> > > > >
> > > > > Updated output files:
> > > > >    https://www.rfc-editor.org/authors/rfc9514.txt
> > > > >    https://www.rfc-editor.org/authors/rfc9514.pdf
> > > > >    https://www.rfc-editor.org/authors/rfc9514.html
> > > > >
> > > > > Diff file showing all changes made during AUTH48:
> > > > >    https://www.rfc-editor.org/authors/rfc9514-auth48diff.html
> > > > >
> > > > > Diff files showing all changes:
> > > > >    https://www.rfc-editor.org/authors/rfc9514-diff.html
> > > > >    https://www.rfc-editor.org/authors/rfc9514-rfcdiff.html
> (side-by-side diff)
> > > > >    https://www.rfc-editor.org/authors/rfc9514-alt-diff.html
> > > > > (diff showing changes where text is moved or deleted)
> > > > >
> > > > > Note that it may be necessary for you to refresh your browser to view
> the most recent version.
> > > > >
> > > > > For the AUTH48 status of this document, please see:
> > > > >   https://www.rfc-editor.org/auth48/rfc9514
> > > > >
> > > > > Thank you!
> > > > > RFC Editor/mc
> > > > >
> > > > > > On Nov 7, 2023, at 4:43 PM, Ketan Talaulikar
> <[e-mail]> wrote:
> > > > > >
> > > > > > Hi Madison,
> > > > > >
> > > > > > Some comments on the changes made:
> > > > > >
> > > > > > a) Sec 7.2
> > > > > > The BGP PeerNode SID and PeerSet SID SIDs
> > > > > >
> > > > > > The "and" is required above.
> > > > > >
> > > > > > b) The caption for Table 1 is not correct - perhaps it should be
> "Addition to NLRI Types registry"
> > > > > >
> > > > > >
> > > > > > Please check inline below for responses.
> > > > > >
> > > > > >
> > > > > > On Mon, Nov 6, 2023 at 4:43 PM Madison Church
> <[e-mail]> wrote:
> > > > > > Greetings,
> > > > > >
> > > > > > This is a friendly weekly reminder that this document awaits your
> attention.  Please review the document-specific questions and AUTH48
> announcement. Let us know if we can be of assistance as you begin the
> AUTH48 review process.
> > > > > >
> > > > > > The AUTH48 status page of this document is viewable at:
> > > > > >
> > > > > > http://www.r/
> > > > > >
> fc-editor.org%2Fauth48%2Frfc9514&data=05%7C01%7Cbruno.decraene
> > > > > > %40orang
> > > > > >
> e.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40bfbc
> 4
> > > > > > 8b9253b6
> > > > > >
> f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3
> d8eyJ
> > > > > > WIjoiMC4
> > > > > >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> > > > > > %7C%7C%7
> > > > > >
> C&sdata=Cpt6r4cCixHPZy1Jq2q7fehFfz6%2BykuZ525O0sHZDrM%3D&reser
> > > > > > ved=0
> > > > > >
> > > > > > The AUTH48 FAQs are available at:
> > > > > >
> > > > > > https://www/.
> > > > > >
> rfc-editor.org%2Ffaq%2F%23auth48&data=05%7C01%7Cbruno.decraene
> > > > > > %40orang
> > > > > >
> e.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40bfbc
> 4
> > > > > > 8b9253b6
> > > > > >
> f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3
> d8eyJ
> > > > > > WIjoiMC4
> > > > > >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> > > > > > %7C%7C%7
> > > > > >
> C&sdata=SHr0rKLNh9zHcfcQvNG5x79H87UNXECZsu0i%2FSRbXLM%3D&rese
> r
> > > > > > ved=0
> > > > > >
> > > > > > We look forward to hearing from you at your earliest convenience.
> > > > > >
> > > > > > Thank you,
> > > > > > RFC Editor/mc
> > > > > >
> > > > > > > On Oct 30, 2023, at 7:08 PM, [e-mail] wrote:
> > > > > > >
> > > > > > > Authors and AD*,
> > > > > > >
> > > > > > > *AD, please see question #1 below.
> > > > > > >
> > > > > > > Authors, while reviewing this document during AUTH48, please
> resolve (as necessary) the following questions, which are also in the XML file.
> > > > > > >
> > > > > > >
> > > > > > > 1) <!-- [rfced] *AD and authors, please let us know if the
> > > > > > > normative reference to RFC 7752 should be updated to 7752bis
> > > > > > > (see https://da/
> > > > > > > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-rfc7752bis%2F17%2F
> > > > > > > &data=05
> > > > > > > %7C01%7Cbruno.decraene%40orange.com%7C02e864ba4d2644a
> e030b08
> > > > > > > dbe2387d
> > > > > > >
> ea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486
> > > > > > > 493467%7
> > > > > > >
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VkPSnTD2bViS
> pByFQArRbM62HNxzuvznG7c3wLqNccM%3D&reserved=0). Note that
> 7752bis was previously approved and then put on hold by the AD, but it is
> now back in EDIT state. If we update to reference 7752bis, both this
> document and RFC-to-be 9513 will be published at the same time as
> 7752bis.
> > > > > >
> > > > > > KT> It is not necessary to update this reference. However, if
> RFC7752bis is getting published "soon" then it does not harm to update.
> > > > > >   >
> > > > > > > Note that this document makes allocations in the "BGP-LS NLRI
> Types"
> > > > > > > and "BGP-LS NLRI and Attribute TLVs" registries.  The
> > > > > > > "BGP-LS NLRI and Attribute TLVs" registry was called the
> > > > > > > "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor,
> > > > > > > and Attribute TLVs" registry in RFC 7752 and changed by
> > > > > > > 7752bis. The name currently in the IANA registry is "BGP-LS
> > > > > > > NLRI and Attribute TLVs". See
> https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xht
> ml#node-descriptor-link-descriptor-prefix-descriptor-attribute-tlv.
> > > > > > >
> > > > > > > If you choose to retain the reference to RFC 7752, we will
> > > > > > > use the registry name in that document ("BGP-LS Node
> > > > > > > Descriptor, Link Descriptor, Prefix Descriptor, and
> > > > > > > Attribute TLVs"). If you choose to wait to publish at the
> > > > > > > same time as 7752bis, we will use the updated name ("BGP-LS
> NLRI and Attribute TLVs").
> > > > > > > -->
> > > > > >
> > > > > > KT> Please see my response to the previous comment.
> > > > > >   >
> > > > > > >
> > > > > > > 2) <!-- [rfced] Please note that the title of the document
> > > > > > > has been updated as follows. Abbreviations have been
> > > > > > > expanded per Section 3.6 of RFC 7322 ("RFC Style Guide").
> > > > > > >
> > > > > > > Original:
> > > > > > >  BGP Link State Extensions for SRv6
> > > > > > >
> > > > > > > Current:
> > > > > > >  Border Gateway Protocol - Link State (BGP-LS) Extensions
> > > > > > > for Segment Routing over IPv6 (SRv6)
> > > > > > > -->
> > > > > >
> > > > > > KT> Agree
> > > > > >   >
> > > > > > >
> > > > > > > 3) <!-- [rfced] Would it be helpful to clarity "a separate document"
> > > > > > > here? Is this referring to a particular RFC?
> > > > > > >
> > > > > > > Original:
> > > > > > >   The BGP-LS address-family solution for SRv6
> > > > > > >   described in this document is similar to BGP-LS for SR for the
> MPLS
> > > > > > >   data-plane defined in a separate document.
> > > > > > > -->
> > > > > >
> > > > > > KT> Yes, that separate document is RFC9085.
> > > > > >   >
> > > > > > >
> > > > > > > 4) <!-- [rfced] We see two instances each of the following
> > > > > > > phrases in this document. May we update to one form for
> consistency?
> > > > > > >
> > > > > > > ...using Direct as the Protocol-ID ...using Direct
> > > > > > > Protocol-ID
> > > > > > > -->
> > > > > >
> > > > > > KT> The first one seems better.
> > > > > >   >
> > > > > > >
> > > > > > > 5) <!-- [rfced] Should "and using" here be updated to either "using"
> or "and uses"?
> > > > > > >
> > > > > > > Original:
> > > > > > >   The SRv6 information pertaining to a node is advertised via the
> BGP-
> > > > > > >   LS Node NLRI and using the BGP-LS Attribute TLVs as follows:
> > > > > > >   ...
> > > > > > >   The SRv6 information pertaining to a link is advertised via the
> BGP-
> > > > > > >   LS Link NLRI and using the BGP-LS Attribute TLVs as follows:
> > > > > > >   ...
> > > > > > >   The SRv6 information pertaining to a prefix is advertised via the
> > > > > > >   BGP-LS Prefix NLRI and using the BGP-LS Attribute TLVs as
> follows:
> > > > > > >
> > > > > > > Perhaps ("using"):
> > > > > > >   The SRv6 information pertaining to a node is advertised via the
> BGP-
> > > > > > >   LS Node NLRI using the BGP-LS Attribute TLVs as follows:
> > > > > > >   ...
> > > > > > >   The SRv6 information pertaining to a link is advertised via the
> BGP-
> > > > > > >   LS Link NLRI using the BGP-LS Attribute TLVs as follows:
> > > > > > >   ...
> > > > > > >   The SRv6 information pertaining to a prefix is advertised via the
> > > > > > >   BGP-LS Prefix NLRI using the BGP-LS Attribute TLVs as follows:
> > > > > > >
> > > > > > > Or ("and uses"):
> > > > > > >   The SRv6 information pertaining to a node is advertised via the
> BGP-
> > > > > > >   LS Node NLRI and uses the BGP-LS Attribute TLVs as follows:
> > > > > > >   ...
> > > > > > >   The SRv6 information pertaining to a link is advertised via the
> BGP-
> > > > > > >   LS Link NLRI and uses the BGP-LS Attribute TLVs as follows:
> > > > > > >   ...
> > > > > > >   The SRv6 information pertaining to a prefix is advertised via the
> > > > > > >   BGP-LS Prefix NLRI and uses the BGP-LS Attribute TLVs as
> follows:
> > > > > > > -->
> > > > > >
> > > > > > KT> Your suggestion with "using" is more appropriate.
> > > > > >   >
> > > > > > >
> > > > > > > 6) <!-- [rfced] Please clarify "are identical as specified"
> > > > > > > here. Is the meaning that the new MSD types in this document
> > > > > > > have the same description and semantics as the MSD types
> > > > > > > defined in [I-D.ietf-lsr-isis-srv6-extensions]? Note that
> > > > > > > this sentence appears twice in the document.
> > > > > > >
> > > > > > > Original:
> > > > > > >   The description and semantics of these new MSD-
> > > > > > >   types for BGP-LS are identical as specified in
> > > > > > >   [I-D.ietf-lsr-isis-srv6-extensions].
> > > > > > >
> > > > > > > Perhaps:
> > > > > > >   The description and semantics of these new MSD-
> > > > > > >   types for BGP-LS are identical to those specified in
> > > > > > >   [RFC9352].
> > > > > > > -->
> > > > > >
> > > > > > KT> Agree with your proposal.
> > > > > >   >
> > > > > > >
> > > > > > > 7) <!-- [rfced] Please clarify "for IGPs, direct, and static
> configuration" here.
> > > > > > >
> > > > > > > Original:
> > > > > > >   *  Local Node Descriptors TLV: set of Node Descriptor TLVs for
> the
> > > > > > >      local node, as defined in [RFC7752] for IGPs, direct, and
> static
> > > > > > >      configuration or as defined in [RFC9086] for BGP protocol.
> > > > > > >
> > > > > > > Perhaps:
> > > > > > >   Local Node Descriptors TLV:  Set of Node Descriptor TLVs for
> the
> > > > > > >      local node as defined in [RFC7752] for IGPs, the Direct
> Protocol-ID,
> > > > > > >      and the Static configuration Protocol-ID or as defined in
> [RFC9086] for BGP.
> > > > > > > -->
> > > > > >
> > > > > > KT> Agree with your proposal.
> > > > > >   >
> > > > > > >
> > > > > > > 8) <!-- [rfced] How may we update this text for clarity?
> > > > > > >
> > > > > > > Original:
> > > > > > >   For SRv6 SIDs corresponding to BGP EPE and when advertising
> SRv6 SID
> > > > > > >   using Direct Protocol-ID, none are defined currently and they
> MUST
> > > > > > >   be set to 0 when originated and ignored on receipt.
> > > > > > >
> > > > > > > Perhaps:
> > > > > > >   No flags are currently defined for SRv6 SIDs corresponding to
> BGP EPE
> > > > > > >   or for advertisement of a SRv6 SID using the Direct Protocol-ID.
> Flags MUST
> > > > > > >   be set to 0 when originated and ignored on receipt.
> > > > > > > -->
> > > > > >
> > > > > > KT> Agree with your proposal.
> > > > > >   >
> > > > > > >
> > > > > > > 9) <!-- [rfced] We have updated "SET" to "set" at the end of
> > > > > > > this sentence. Please let us know any objections.
> > > > > > >
> > > > > > > Original:
> > > > > > >   For SRv6 BGP EPE Peer Set SID,
> > > > > > >   multiple instances of this TLV (one for each peer in the "peer
> set")
> > > > > > >   are associated with the SRv6 SID and the S-Flag is SET.
> > > > > > > -->
> > > > > >
> > > > > > KT> Agree.
> > > > > >   >
> > > > > > >
> > > > > > > 10) <!-- [rfced] Section 9.2: FYI - We have updated the name
> > > > > > > of the registry in this section to "BGP-LS NLRI and
> > > > > > > Attribute TLVs" to match the title currently in the IANA
> > > > > > > registry (renamed per draft-ietf-idr-rfc7752bis). Depending
> > > > > > > on the response to our question #1, we will either use the
> > > > > > > name of the registry per RFC
> > > > > > > 7752 ("BGP-LS Node Descriptor, Link Descriptor, Prefix
> > > > > > > Descriptor, and Attribute TLVs") or the name per
> draft-ietf-idr-rfc7752bis ("BGP-LS NLRI and Attribute TLVs").
> > > > > > >
> > > > > > > Link to registry:
> > > > > > > https://ww/
> > > > > > >
> w.iana.org%2Fassignments%2Fbgp-ls-parameters%2Fbgp-ls-parame
> > > > > > > ters.xht
> > > > > > > ml%23node-descriptor-link-descriptor-prefix-descriptor-attri
> > > > > > > bute-tlv
> > > > > > >
> &data=05%7C01%7Cbruno.decraene%40orange.com%7C02e864ba4d2644
> > > > > > > ae030b08
> > > > > > >
> dbe2387dea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> > > > > > > 52504486
> > > > > > >
> 493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > > > > > > 2luMzIiL
> > > > > > >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gaQ%2FEI
> > > > > > > 6K85rcFc
> > > > > > > REDGBmBklZCqyiaN2x6y06GocnAks%3D&reserved=0
> > > > > > > -->
> > > > > >
> > > > > > KT> Please refer to my response to the first point.
> > > > > >   >
> > > > > > >
> > > > > > > 11) <!-- [rfced] Please confirm that "set up to routers" is correct.
> > > > > > > Or should this be updated to "set up for routers" ("for"
> > > > > > > instead of "to")? Also, is the capitaliation of "Link-State" correct?
> > > > > > >
> > > > > > > Original:
> > > > > > >   BGP peering sessions for
> > > > > > >   address-families other than Link-State may be set up to routers
> > > > > > >   outside the SR domain.
> > > > > > > -->
> > > > > >
> > > > > > KT> "set up to" is correct and the capitalization is correct as well.
> > > > > >   >
> > > > > > >
> > > > > > > 12) <!-- [rfced] Terminology
> > > > > > >
> > > > > > > a) We note inconsistencies in the terms below throughout the text.
> > > > > > > Should either the closed or open form be used consistently?
> > > > > > > Or should "PeerSet" and "PeerNode" be used when followed by
> "SID", and then "Peer Set" and "Peer Node"
> > > > > > > be used elsewhere? We see "PeerSet SID" in RFCs 8402 and
> > > > > > > 9086, and we see "PeerNode SID" in RFC 9086.
> > > > > > >
> > > > > > > PeerSet vs. Peer Set
> > > > > > >
> > > > > > > PeerNode vs. Peer Node
> > > > > >
> > > > > > KT> We should follow RFC8402 and RFC9086.
> > > > > >   >
> > > > > > >
> > > > > > > b) This relates to the question above. The name of the TLV
> > > > > > > defined in Section
> > > > > > > 7.2 is "SRv6 BGP Peer Node SID TLV". Should this be updated
> > > > > > > to "SRv6 BGP PeerNode SID TLV" (with "PeerNode" rather than
> > > > > > > "Peer Node")? If so, we will ask IANA to update the registry
> accordingly prior to publication.
> > > > > > >
> > > > > > > Link to registry:
> > > > > > > https://ww/
> > > > > > >
> w.iana.org%2Fassignments%2Fbgp-ls-parameters%2Fbgp-ls-parame
> > > > > > > ters.xht
> > > > > > >
> ml%23srv6-bgp-epe-sid&data=05%7C01%7Cbruno.decraene%40orange
> > > > > > > .com%7C0
> > > > > > >
> 2e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40bfbc48b9253b
> > > > > > > 6f5d20%7
> > > > > > >
> C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oi
> > > > > > > MC4wLjAw
> > > > > > >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> > > > > > > %7C%7C&s
> > > > > > >
> data=UZTWlxX52BAcCCG4ksC44OVyygPlgW8pvf0iv6m9wh8%3D&reserved
> > > > > > > =0
> > > > > > >
> > > > > >
> > > > > > KT> Agree. Let us update as per the terminology in RFC8402/9086.
> > > > > >
> > > > > > >
> > > > > > > c) May we update the instance of "peer sessions" in this
> > > > > > > sentence to "peering sessions" to match usage elsewhere in the
> document?
> > > > > > >
> > > > > > > Original:
> > > > > > >   ...therefore MAY be assigned to one or more
> > > > > > >   End.X SIDs associated with BGP peer sessions.
> > > > > >
> > > > > > KT> "peering sessions" is more appropriate.
> > > > > >   >
> > > > > > >
> > > > > > > d) FYI, we updated "SRv6 BGP EPE Peer Node SID TLV" to "SRv6
> BGP Peer Node SID TLV"
> > > > > > > (no "EPE") for consistency with the name used elswhere in the
> document.
> > > > > > >
> > > > > > > Original:
> > > > > > >   *  The BGP EPE Peer Node context for a PeerNode SID, and the
> Peer Set
> > > > > > >      context for a PeerSet SID [RFC8402] are advertised via the
> SRv6
> > > > > > >      BGP EPE Peer Node SID TLV (Section 7.2),
> > > > > > >
> > > > > >
> > > > > > KT> Agree.
> > > > > >
> > > > > > >
> > > > > > > e) FYI, we updated "OSPFv3 SRv6 LAN End.X sub-TLV" here to
> > > > > > > "OSPFv3
> > > > > > > SRv6 LAN End.X SID sub-TLV" (with "SID") to match usage in
> > > > > > > Section
> > > > > > > 9.2 of RFC-to-be 9513.
> > > > > > >
> > > > > > > Original:
> > > > > > >   The information advertised via this TLV is derived from the IS-IS
> SRv6
> > > > > > >   LAN End.X SID sub-TLV (section 8.2 of
> > > > > > >   [I-D.ietf-lsr-isis-srv6-extensions]) or the OSPFv3 SRv6 LAN End.X
> > > > > > >   sub-TLV (section 9.2 of [I-D.ietf-lsr-ospfv3-srv6-extensions]) in
> the
> > > > > > >   case of IS-IS or OSPFv3 respectively.
> > > > > > > -->
> > > > > >
> > > > > > KT> Agree. "SID" is required in the name.
> > > > > >   >
> > > > > > >
> > > > > > > 13) <!-- [rfced] Please review the "Inclusive Language"
> > > > > > > portion of the online Style Guide <https://w/
> > > > > > > ww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_langua
> > > > > > > ge&data=
> > > > > > >
> 05%7C01%7Cbruno.decraene%40orange.com%7C02e864ba4d2644ae030b
> > > > > > > 08dbe238
> > > > > > >
> 7dea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383525044
> 86493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e
> xDdgSsc6tdwamgMDodmQ%2BHPbUePBXozcdbw9T75RMI%3D&reserved=0>
> 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.
> > > > > > > -->
> > > > > >
> > > > > > KT> Ack
> > > > > >   >
> > > > > > >
> > > > > > > 14) <!-- [rfced] FYI - Expansions for abbreviations have
> > > > > > > been added upon first use per Section 3.6 of RFC 7322 ("RFC Style
> Guide").
> > > > > > > Please review each expansion in the document carefully to ensure
> correctness.
> > > > > > > -->
> > > > > >
> > > > > > KT> Ack.
> > > > > >
> > > > > > Thanks,
> > > > > > Ketan
> > > > > >   >
> > > > > > >
> > > > > > > Thank you.
> > > > > > >
> > > > > > > RFC Editor/mc/rv
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Oct 30, 2023, at 5:05 PM, [e-mail] wrote:
> > > > > > >
> > > > > > > *****IMPORTANT*****
> > > > > > >
> > > > > > > Updated 2023/10/30
> > > > > > >
> > > > > > > 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://ma/
> > > > > > > ilarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4
> > > > > > > Q9l2USxI
> > > > > > >
> Ae6P8O4Zc&data=05%7C01%7Cbruno.decraene%40orange.com%7C02e86
> > > > > > > 4ba4d264
> > > > > > >
> 4ae030b08dbe2387dea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> > > > > > > C0%7C638
> > > > > > >
> 352504486493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> Ai
> > > > > > > LCJQIjoi
> > > > > > >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> > > > > > > =U4IolTk
> > > > > > >
> j8YKrHM%2FvbnP1WbG0hs%2FCb8SBifs1WvKPLFI%3D&reserved=0
> > > > > > >
> > > > > > >    *  The archive itself:
> > > > > > >
> > > > > > > https://ma/
> > > > > > > ilarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=0
> > > > > > > 5%7C01%7
> > > > > > >
> Cbruno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387
> > > > > > > dea%7C90
> > > > > > >
> c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%
> > > > > > > 7CUnknow
> > > > > > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> > > > > > > Ik1haWwi
> > > > > > >
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DiyAgpAs1s2VtrPlcezzljS
> > > > > > > 5gNacJxY
> > > > > > > I0w6AbcUXKYE%3D&reserved=0
> > > > > > >
> > > > > > >    *  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://ww/
> > > > > > >
> w.rfc-editor.org%2Fauthors%2Frfc9514.xml&data=05%7C01%7Cbrun
> > > > > > > o.decrae
> > > > > > >
> ne%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20
> > > > > > > af34b40b
> > > > > > >
> fbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7
> CT
> > > > > > > WFpbGZsb
> > > > > > >
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> > > > > > > CI6Mn0%3
> > > > > > >
> D%7C3000%7C%7C%7C&sdata=3hjxa25isot30zH4qOaVjffg%2BjtV1NMn2P
> > > > > > > sGUL3Bkc
> > > > > > > 0%3D&reserved=0
> > > > > > >
> > > > > > > https://ww/
> > > > > > >
> w.rfc-editor.org%2Fauthors%2Frfc9514.html&data=05%7C01%7Cbru
> > > > > > > no.decra
> > > > > > >
> ene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a2
> > > > > > > 0af34b40
> > > > > > >
> bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%
> 7C
> > > > > > > TWFpbGZs
> > > > > > >
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > > > > VCI6Mn0%
> > > > > > >
> 3D%7C3000%7C%7C%7C&sdata=vogzFVWlNhp0vVadB%2BIzI9Fwt0HZYX7%2
> > > > > > > B%2BYXpP
> > > > > > > HB8b2c%3D&reserved=0
> > > > > > >
> > > > > > > https://ww/
> > > > > > >
> w.rfc-editor.org%2Fauthors%2Frfc9514.pdf&data=05%7C01%7Cbrun
> > > > > > > o.decrae
> > > > > > >
> ne%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20
> > > > > > > af34b40b
> > > > > > >
> fbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7
> CT
> > > > > > > WFpbGZsb
> > > > > > >
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> > > > > > > CI6Mn0%3
> > > > > > >
> D%7C3000%7C%7C%7C&sdata=PL51%2Becu%2BUfcgXbqZemAcA9NWZkI0e2
> L
> > > > > > > oUN1kS20
> > > > > > > 2S8%3D&reserved=0
> > > > > > >
> > > > > > > https://ww/
> > > > > > >
> w.rfc-editor.org%2Fauthors%2Frfc9514.txt&data=05%7C01%7Cbrun
> > > > > > > o.decrae
> > > > > > >
> ne%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20
> > > > > > > af34b40b
> > > > > > >
> fbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7
> CT
> > > > > > > WFpbGZsb
> > > > > > >
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> > > > > > > CI6Mn0%3
> > > > > > >
> D%7C3000%7C%7C%7C&sdata=hf%2BceMNvDnTTMCYz%2FqLdhi39ynjAWm
> GF
> > > > > > > 5JSocfXz
> > > > > > > iAI%3D&reserved=0
> > > > > > >
> > > > > > > Diff file of the text:
> > > > > > >
> > > > > > > https://ww/
> > > > > > >
> w.rfc-editor.org%2Fauthors%2Frfc9514-diff.html&data=05%7C01%7Cbruno.
> > > > > > >
> decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C9
> > > > > > > 0c7a20af
> > > > > > >
> 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnkn
> o
> > > > > > > wn%7CTWF
> > > > > > >
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> > > > > > > iLCJXVCI
> > > > > > >
> 6Mn0%3D%7C3000%7C%7C%7C&sdata=U8sk09rMHCF1DwT4ng7fr%2FcCkj
> dh
> > > > > > > 5VX2CYFj
> > > > > > > J8YRl14%3D&reserved=0
> > > > > > >
> > > > > > > https://ww/
> > > > > > > w.rfc-editor.org%2Fauthors%2Frfc9514-rfcdiff.html&data=05%7C
> > > > > > > 01%7Cbru
> > > > > > >
> no.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%
> > > > > > > 7C90c7a2
> > > > > > >
> 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CU
> n
> > > > > > > known%7C
> > > > > > >
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> > > > > > > aWwiLCJX
> > > > > > >
> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fXvKQuSk1aA%2FKlZPq3Jv6luqg
> > > > > > > qLqpbay4
> > > > > > > eFdxPNnqJM%3D&reserved=0 (side by side)
> > > > > > >
> > > > > > > Alt-diff of the text (allows you to more easily view changes
> > > > > > > where text has been deleted or moved):
> > > > > > >
> > > > > > > https://ww/
> > > > > > > w.rfc-editor.org%2Fauthors%2Frfc9514-alt-diff.html&data=05%7
> > > > > > > C01%7Cbr
> > > > > > >
> uno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea
> > > > > > > %7C90c7a
> > > > > > >
> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7C
> U
> > > > > > > nknown%7
> > > > > > >
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > > > > > > haWwiLCJ
> > > > > > >
> XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tSt9ITE4h6MMIgWjAbdYxBm2
> N8
> > > > > > > %2FT93nG
> > > > > > > vcfSBchLHZ0%3D&reserved=0
> > > > > > >
> > > > > > > Diff of the XML:
> > > > > > >
> > > > > > > https://ww/
> > > > > > > w.rfc-editor.org%2Fauthors%2Frfc9514-xmldiff1.html&data=05%7
> > > > > > > C01%7Cbr
> > > > > > >
> uno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea
> > > > > > > %7C90c7a
> > > > > > >
> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7C
> U
> > > > > > > nknown%7
> > > > > > >
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > > > > > > haWwiLCJ
> > > > > > >
> XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Xe6dSLHb65hdHe2Oz8hrSzaOV
> u
> > > > > > > R3KRpaZy
> > > > > > > 6UbMBdpJs%3D&reserved=0
> > > > > > >
> > > > > > > The following files are provided to facilitate creation of
> > > > > > > your own diff files of the XML.
> > > > > > >
> > > > > > > Initial XMLv3 created using XMLv2 as input:
> > > > > > >
> > > > > > > https://ww/
> > > > > > > w.rfc-editor.org%2Fauthors%2Frfc9514.original.v2v3.xml&data=
> > > > > > > 05%7C01%
> > > > > > >
> 7Cbruno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe238
> > > > > > > 7dea%7C9
> > > > > > >
> 0c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467
> > > > > > > %7CUnkno
> > > > > > >
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > > > > > > 6Ik1haWw
> > > > > > >
> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vYjEfnLT1Kfyxt5Vqd3eWE
> > > > > > > dnh7xtR%
> > > > > > > 2BSpTwRPjKyhxmQ%3D&reserved=0
> > > > > > >
> > > > > > > XMLv3 file that is a best effort to capture v3-related
> > > > > > > format updates
> > > > > > > only:
> > > > > > >
> > > > > > > https://ww/
> > > > > > >
> w.rfc-editor.org%2Fauthors%2Frfc9514.form.xml&data=05%7C01%7
> > > > > > > Cbruno.d
> > > > > > >
> ecraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90
> > > > > > > c7a20af3
> > > > > > >
> 4b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnkno
> w
> > > > > > > n%7CTWFp
> > > > > > >
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > > > > > > LCJXVCI6
> > > > > > >
> Mn0%3D%7C3000%7C%7C%7C&sdata=22Zu%2FkhmNXZjqm%2BXlbYvqIQ3
> Ht4
> > > > > > > %2BzN4zB
> > > > > > > yZiFs3PMfc%3D&reserved=0
> > > > > > >
> > > > > > >
> > > > > > > Tracking progress
> > > > > > > -----------------
> > > > > > >
> > > > > > > The details of the AUTH48 status of your document are here:
> > > > > > >
> > > > > > > https://ww/
> > > > > > >
> w.rfc-editor.org%2Fauth48%2Frfc9514&data=05%7C01%7Cbruno.dec
> > > > > > > raene%40
> > > > > > >
> orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b
> > > > > > > 40bfbc48
> > > > > > >
> b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWF
> pbG
> > > > > > > Zsb3d8ey
> > > > > > >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > > > > > > 0%3D%7C3
> > > > > > >
> 000%7C%7C%7C&sdata=NKnzK%2BxVtkXGPQyQlvkH%2B6qmqO29jxK%2Fd
> wj
> > > > > > > iH2EV2%2
> > > > > > > BI%3D&reserved=0
> > > > > > >
> > > > > > > Please let us know if you have any questions.
> > > > > > >
> > > > > > > Thank you for your cooperation,
> > > > > > >
> > > > > > > RFC Editor
> > > > > > >
> > > > > > > --------------------------------------
> > > > > > > RFC9514 (draft-ietf-idr-bgpls-srv6-ext-14)
> > > > > > >
> > > > > > > Title            : BGP Link State Extensions for SRv6
> > > > > > > Author(s)        : G. Dawra, C. Filsfils, K. Talaulikar, M. Chen, D.
> Bernier, B. Decraene
> > > > > > > WG Chair(s)      : Susan Hares, Keyur Patel, Jeffrey Haas
> > > > > > >
> > > > > > > Area Director(s) : Alvaro Retana, John Scudder, Andrew
> > > > > > > Alston
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> ________________________________________________________________
> > > > > ____________________________________________
> > > > > Ce message et ses pieces jointes peuvent contenir des
> > > > > informations confidentielles ou privilegiees et ne doivent donc
> > > > > pas etre diffuses, exploites ou copies sans autorisation. Si
> > > > > vous avez recu ce message par erreur, veuillez le signaler a l'expediteur
> et le detruire ainsi que les pieces jointes. Les messages electroniques etant
> susceptibles d'alteration, Orange decline toute responsabilite si ce message a
> ete altere, deforme ou falsifie. Merci.
> > > > >
> > > > > This message and its attachments may contain confidential or
> > > > > privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> > > > > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > > > > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > > > > Thank you.
> > > >
> > > >
> > >
> >
> >
> > Orange Restricted
> >
> ___________________________________________________________________
> ___
> > _____________________________________
> > _
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> > Thank you.
> >
> 
>