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

[Ketan Talaulikar <[e-mail]>]

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%7C90c7a20af34b40bfbc48b9253b6
> > f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > C&sdata=Cpt6r4cCixHPZy1Jq2q7fehFfz6%2BykuZ525O0sHZDrM%3D&reserved=0
> >
> > The AUTH48 FAQs are available at:
> >
> > https://www/.
> > rfc-editor.org%2Ffaq%2F%23auth48&data=05%7C01%7Cbruno.decraene%40orang
> > e.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40bfbc48b9253b6
> > f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > C&sdata=SHr0rKLNh9zHcfcQvNG5x79H87UNXECZsu0i%2FSRbXLM%3D&reserved=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%7C02e864ba4d2644ae030b08dbe2387d
> > > ea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7
> > >
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VkPSnTD2bViSpByFQArRbM62HNxzuvznG7c3wLqNccM%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.xhtml#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-parameters.xht
> > > ml%23node-descriptor-link-descriptor-prefix-descriptor-attribute-tlv
> > > &data=05%7C01%7Cbruno.decraene%40orange.com%7C02e864ba4d2644ae030b08
> > > dbe2387dea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486
> > > 493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gaQ%2FEI6K85rcFc
> > > 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-parameters.xht
> > > ml%23srv6-bgp-epe-sid&data=05%7C01%7Cbruno.decraene%40orange.com%7C0
> > > 2e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> > > C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > > 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_language&data=
> > > 05%7C01%7Cbruno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe238
> > >
> 7dea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=exDdgSsc6tdwamgMDodmQ%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-4Q9l2USxI
> > > Ae6P8O4Zc&data=05%7C01%7Cbruno.decraene%40orange.com%7C02e864ba4d264
> > > 4ae030b08dbe2387dea%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> > > 352504486493467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> > > 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=05%7C01%7
> > > Cbruno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90
> > > c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknow
> > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > > LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DiyAgpAs1s2VtrPlcezzljS5gNacJxY
> > > 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%7Cbruno.decrae
> > > ne%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40b
> > > fbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb
> > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > D%7C3000%7C%7C%7C&sdata=3hjxa25isot30zH4qOaVjffg%2BjtV1NMn2PsGUL3Bkc
> > > 0%3D&reserved=0
> > >
> > > https://ww/
> > > w.rfc-editor.org%2Fauthors%2Frfc9514.html&data=05%7C01%7Cbruno.decra
> > > ene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40
> > > bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZs
> > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > > 3D%7C3000%7C%7C%7C&sdata=vogzFVWlNhp0vVadB%2BIzI9Fwt0HZYX7%2B%2BYXpP
> > > HB8b2c%3D&reserved=0
> > >
> > > https://ww/
> > > w.rfc-editor.org%2Fauthors%2Frfc9514.pdf&data=05%7C01%7Cbruno.decrae
> > > ne%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40b
> > > fbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb
> > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > D%7C3000%7C%7C%7C&sdata=PL51%2Becu%2BUfcgXbqZemAcA9NWZkI0e2LoUN1kS20
> > > 2S8%3D&reserved=0
> > >
> > > https://ww/
> > > w.rfc-editor.org%2Fauthors%2Frfc9514.txt&data=05%7C01%7Cbruno.decrae
> > > ne%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40b
> > > fbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb
> > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > D%7C3000%7C%7C%7C&sdata=hf%2BceMNvDnTTMCYz%2FqLdhi39ynjAWmGF5JSocfXz
> > > 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%7C90c7a20af
> > > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWF
> > > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > > 6Mn0%3D%7C3000%7C%7C%7C&sdata=U8sk09rMHCF1DwT4ng7fr%2FcCkjdh5VX2CYFj
> > > J8YRl14%3D&reserved=0
> > >
> > > https://ww/
> > > w.rfc-editor.org%2Fauthors%2Frfc9514-rfcdiff.html&data=05%7C01%7Cbru
> > > no.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a2
> > > 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7C
> > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fXvKQuSk1aA%2FKlZPq3Jv6luqgqLqpbay4
> > > 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%7C01%7Cbr
> > > uno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a
> > > 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7
> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> > > XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tSt9ITE4h6MMIgWjAbdYxBm2N8%2FT93nG
> > > vcfSBchLHZ0%3D&reserved=0
> > >
> > > Diff of the XML:
> > >
> > > https://ww/
> > > w.rfc-editor.org%2Fauthors%2Frfc9514-xmldiff1.html&data=05%7C01%7Cbr
> > > uno.decraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a
> > > 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7
> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> > > XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Xe6dSLHb65hdHe2Oz8hrSzaOVuR3KRpaZy
> > > 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%7C02e864ba4d2644ae030b08dbe2387dea%7C9
> > > 0c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnkno
> > > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> > > iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vYjEfnLT1Kfyxt5Vqd3eWEdnh7xtR%
> > > 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%7Cbruno.d
> > > ecraene%40orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af3
> > > 4b40bfbc48b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFp
> > > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > > Mn0%3D%7C3000%7C%7C%7C&sdata=22Zu%2FkhmNXZjqm%2BXlbYvqIQ3Ht4%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.decraene%40
> > > orange.com%7C02e864ba4d2644ae030b08dbe2387dea%7C90c7a20af34b40bfbc48
> > > b9253b6f5d20%7C0%7C0%7C638352504486493467%7CUnknown%7CTWFpbGZsb3d8ey
> > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> > > 000%7C%7C%7C&sdata=NKnzK%2BxVtkXGPQyQlvkH%2B6qmqO29jxK%2FdwjiH2EV2%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.
>