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

[Alanna Paloma <[e-mail]>]

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