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

[Gaurav Dawra <[e-mail]>]

Hi,

I approve 

Gaurav

Sent from my iPhone

> On Nov 22, 2023, at 1:59 PM, Clarence Filsfils (cfilsfil) <[e-mail]> wrote:
> 
> 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.
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>