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

["Clarence Filsfils (cfilsfil)" <[e-mail]>]

Hello,

I approve.

Cheers,
Clarence

> -----Original Message-----
> From: Alanna Paloma <[e-mail]>
> Sent: Wednesday, November 22, 2023 02:52
> To: Mach Chen <[e-mail]>; [e-mail]
> Cc: DECRAENE Bruno INNOV/NET <[e-mail]>; Ketan
> Talaulikar <[e-mail]>; Madison Church <[e-mail]>;
> Clarence Filsfils (cfilsfil) <[e-mail]>; [e-mail]; Alvaro
> Retana <[e-mail]>; RFC Editor <[e-mail]>; idr-
> [e-mail]; [e-mail]; [e-mail]; auth48archive@rfc-
> editor.org
> Subject: Re: [AD] AUTH48: RFC-to-be 9514 <draft-ietf-idr-bgpls-srv6-ext-14> for
> your review
> 
> Hi Daniel and Mach,
> 
> Your approvals have been noted on the AUTH48 status page:
>  https://www.rfc-editor.org/auth48/rfc9514
> 
> Thank you,
> RFC Editor/ap
> 
> > On Nov 21, 2023, at 5:11 PM, Mach Chen <[e-mail]> wrote:
> >
> > 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
> >>>>> KT> 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.
> >>>
> >>
> >>
> >
>