Re: [auth48] [IANA #1232801] [IANA] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-services-15> for your review

[Alanna Paloma <[e-mail]>]

Thank you!

RFC Editor/ap

> On Jul 1, 2022, at 4:12 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi all,
> 
> Sorry about the delay. This change has been made:
> 
> https://www.iana.org/assignments/bgp-parameters
> 
> Best regards,
> 
> Amanda Baber
> IANA Operations Manager
> 
> On Tue Jun 28 18:08:29 2022, [e-mail] wrote:
>> IANA,
>> 
>> Please update your registries as follows to match the edited document
>> at https://www.rfc-editor.org/authors/rfc9252-diff.html.
>> 
>> Please update the “BGP Prefix-SID TLV Types” registry
>> <https://www.iana.org/assignments/bgp-parameters/bgp-
>> parameters.xhtml#bgp-prefix-sid-tlv-types>
>> to add “TLV” to "SRv6 L3 Service” and "SRv6 L2 Service".
>> 
>> Old:
>> Value   Type                    Reference
>> 5               SRv6 L3 Service [RFC-ietf-bess-srv6-services-15]
>> 6               SRv6 L2 Service [RFC-ietf-bess-srv6-services-15]
>> 
>> New:
>> Value   Type                            Reference
>> 5               SRv6 L3 Service TLV     [RFC-ietf-bess-srv6-services-
>> 15]
>> 6               SRv6 L2 Service TLV     [RFC-ietf-bess-srv6-services-
>> 15]
>> 
>> Best regards,
>> RFC Editor/ap
>> 
>>> On Jun 24, 2022, at 9:51 PM, Gaurav Dawra <[e-mail]>
>>> wrote:
>>> 
>>> Approved.
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jun 24, 2022, at 1:57 PM, Alanna Paloma <[e-mail]> wrote:
>>>> 
>>>> Hi Ketan and Robert,
>>>> 
>>>> We have updated our files accordingly.
>>>> 
>>>> We will await approval from Gaurav before asking IANA to update
>>>> their registry accordingly.
>>>> When the IANA update is complete, we will move forward with the
>>>> publication process.
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9252
>>>> 
>>>> The files have been posted here (please refresh):
>>>> https://www.rfc-editor.org/authors/rfc9252.xml
>>>> https://www.rfc-editor.org/authors/rfc9252.txt
>>>> https://www.rfc-editor.org/authors/rfc9252.html
>>>> https://www.rfc-editor.org/authors/rfc9252.pdf
>>>> 
>>>> The relevant diff files have been posted here:
>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html (comprehensive
>>>> diff)
>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html (AUTH48
>>>> changes)
>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last
>>>> version to this one)
>>>> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html (last
>>>> version to this one side by side)
>>>> 
>>>> Thank you,
>>>> RFC Editor/ap
>>>> 
>>>>> On Jun 24, 2022, at 12:35 PM, Robert Raszuk <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>> Well since you opened that bxo Kentn,
>>>>> 
>>>>> VRF does not stand as an abbreviation for "VPN Routing and
>>>>> Forwarding table - that is incorrect.
>>>>> 
>>>>> VRF table == Virtual Routing and Forwarding table.
>>>>> 
>>>>> With that the brackets are not needed and the entire description
>>>>> already deserves an errata :)
>>>>> 
>>>>> Thx,
>>>>> R.
>>>>> 
>>>>> On Fri, Jun 24, 2022 at 6:30 PM Ketan Talaulikar
>>>>> <[e-mail]> wrote:
>>>>> Hi Alanna,
>>>>> 
>>>>> A Minor nit came to my attention in Sec 1
>>>>> OLD: End.DT (table look up in VPN Routing and Forwarding (VRF))
>>>>> NEW: End.DT (look up in VPN Routing and Forwarding (VRF) table)
>>>>> 
>>>>> Thanks,
>>>>> Ketan
>>>>> 
>>>>> 
>>>>> On Tue, Jun 21, 2022 at 11:58 PM Alanna Paloma <[e-mail]>
>>>>> wrote:
>>>>> Bruno, Jorge, Ketan, and Shunwan,
>>>>> 
>>>>> Thank you for your replies. Your approvals have been noted on the
>>>>> AUTH48 status page.
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9252
>>>>> 
>>>>> Once we have received approvals from Gaurav and Robert, we will ask
>>>>> IANA to update
>>>>> their registry accordingly. After the IANA updates are complete, we
>>>>> will move forward
>>>>> with the publication process.
>>>>> 
>>>>> Thank you,
>>>>> RFC Editor/ap
>>>>> 
>>>>>>> On Jun 21, 2022, at 5:10 AM, [e-mail] wrote:
>>>>>> 
>>>>>> Hi Alanna, RFC Editor,
>>>>>> 
>>>>>> I approve latest version.
>>>>>> 
>>>>>> Thank you
>>>>>> --Bruno
>>>>>> 
>>>>>> 
>>>>>> Orange Restricted
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Alanna Paloma <[e-mail]>
>>>>>> Sent: Monday, June 20, 2022 11:41 PM
>>>>>> To: Andrew Alston - IETF <[e-mail]>
>>>>>> Cc: Rabadan, Jorge (Nokia - US/Sunnyvale)
>>>>>> <[e-mail]>; Ketan Talaulikar
>>>>>> <[e-mail]>; DECRAENE Bruno INNOV/NET
>>>>>> <[e-mail]>; [e-mail];
>>>>>> [e-mail]; [e-mail]; rfc-editor@rfc-
>>>>>> editor.org; [e-mail]; [e-mail]; Bocci,
>>>>>> Matthew (Nokia - GB) <[e-mail]>; auth48archive@rfc-
>>>>>> editor.org
>>>>>> Subject: Re: AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-
>>>>>> services-15> for your review
>>>>>> 
>>>>>> Hi Andrew,
>>>>>> 
>>>>>> Thank you for your reply. Your approval has been noted on the
>>>>>> AUTH48 status page.
>>>>>> 
>>>>>> https://www.rfc-editor.org/auth48/rfc9252
>>>>>> 
>>>>>> We will await further word from the authors regarding updates
>>>>>> and/or approvals
>>>>>> prior to moving forward in the publication process.
>>>>>> 
>>>>>> Thank you,
>>>>>> RFC Editor/ap
>>>>>> 
>>>>>>> On Jun 20, 2022, at 11:23 AM, Andrew Alston - IETF <andrew-
>>>>>>> [e-mail]> wrote:
>>>>>>> 
>>>>>>> I’m ok with the changes to 3.1 and and the addition in section 2.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> Andrew
>>>>>>> 
>>>>>>> 
>>>>>>> From: Alanna Paloma <[e-mail]>
>>>>>>> Sent: Monday, June 20, 2022 8:22 PM
>>>>>>> To: Rabadan, Jorge (Nokia - US/Sunnyvale)
>>>>>>> <[e-mail]>; Ketan Talaulikar
>>>>>>> <[e-mail]>; Andrew Alston - IETF <andrew-
>>>>>>> [e-mail]>
>>>>>>> Cc: [e-mail]; [e-mail];
>>>>>>> [e-mail]; [e-mail]; rfc-editor@rfc-
>>>>>>> editor.org; [e-mail]; [e-mail]; Bocci,
>>>>>>> Matthew (Nokia - GB) <[e-mail]>;
>>>>>>> [e-mail]
>>>>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-
>>>>>>> services-15> for your review
>>>>>>> 
>>>>>>> Ketan, Jorge, and *Andrew (AD),
>>>>>>> 
>>>>>>> *Andrew (AD) - Please review and approve the change from “SHOULD”
>>>>>>> to “MUST” in
>>>>>>> Section 3.1, as well as the addition of “Layer 2 services” in
>>>>>>> Section 2.
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/authors/rfc9252-ad-diff.html
>>>>>>> 
>>>>>>> Ketan and Jorge - Thank you for your replies. We have updated
>>>>>>> accordingly.
>>>>>>> 
>>>>>>> FYI, we removed the following reference from the References
>>>>>>> section as its only
>>>>>>> occurrence was replaced with [RFC9012] in Section 1 per Ketan's
>>>>>>> request.
>>>>>>> 
>>>>>>> [BGP-SR-POLICY]
>>>>>>> Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
>>>>>>> P., Jain, D., and S. Lin, "Advertising Segment Routing
>>>>>>> Policies in BGP", Work in Progress, Internet-Draft, draft-
>>>>>>> ietf-idr-segment-routing-te-policy-17, 14 April 2022,
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
>>>>>>> segment-routing-te-policy-17>.
>>>>>>> 
>>>>>>> The files have been posted here (please refresh):
>>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml
>>>>>>> https://www.rfc-editor.org/authors/rfc9252.txt
>>>>>>> https://www.rfc-editor.org/authors/rfc9252.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf
>>>>>>> 
>>>>>>> The relevant diff files have been posted here:
>>>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html
>>>>>>> (comprehensive diff)
>>>>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html
>>>>>>> (AUTH48 changes)
>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last
>>>>>>> version to this one)
>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html (last
>>>>>>> version to this one side by side)
>>>>>>> 
>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>> https://www.rfc-editor.org/auth48/rfc9252
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> RFC Editor/ap
>>>>>>> 
>>>>>>>> On Jun 17, 2022, at 11:17 AM, Rabadan, Jorge (Nokia -
>>>>>>>> US/Sunnyvale) <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi Alanna,
>>>>>>>> 
>>>>>>>> I discussed offline with Ketan and we decided to modify a little
>>>>>>>> bit (for clarity) the second change that he suggested in his
>>>>>>>> last email:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> For all occurrences in sections 6.1.1, 6.1.2, 6.2 (two
>>>>>>>> occurrences), 6.2.1, 6.2.2 (two occurrences) and 6.5
>>>>>>>> 
>>>>>>>> OLD: it is set to the Implicit NULL value. In either case, the
>>>>>>>> value is set in the 24 bits (e.g., as 0x000030 in the case of
>>>>>>>> Implicit NULL).
>>>>>>>> NEW: it is set to Implicit NULL in the higher-order 20 bits
>>>>>>>> (i.e., as 0x000030). In either case, the value is set in the 24
>>>>>>>> bits.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please let us know if you have questions.
>>>>>>>> Thank you.
>>>>>>>> Jorge
>>>>>>>> 
>>>>>>>> 
>>>>>>>> From: Ketan Talaulikar <[e-mail]>
>>>>>>>> Date: Friday, June 17, 2022 at 1:32 PM
>>>>>>>> To: Alanna Paloma <[e-mail]>
>>>>>>>> Cc: [e-mail] <[e-mail]>,
>>>>>>>> [e-mail]<[e-mail]>, [e-mail]
>>>>>>>> <[e-mail]>,
>>>>>>>> [e-mail]<[e-mail]>, Rabadan,
>>>>>>>> Jorge (Nokia - US/Sunnyvale) <[e-mail]>, rfc-
>>>>>>>> [e-mail] <[e-mail]>, andrew-
>>>>>>>> [e-mail] <[e-mail]>, [e-mail]
>>>>>>>> <[e-mail]>, [e-mail] <bess-
>>>>>>>> [e-mail]>, Bocci, Matthew (Nokia - GB)
>>>>>>>> <[e-mail]>,[e-mail]
>>>>>>>> <[e-mail]>
>>>>>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-
>>>>>>>> services-15> for your review
>>>>>>>> 
>>>>>>>> Hi Alanna,
>>>>>>>> 
>>>>>>>> There are 2 further changes based on the discussion below about
>>>>>>>> the original "high order 20 bits" error.
>>>>>>>> 
>>>>>>>> https://mailarchive.ietf.org/arch/msg/bess/VN3_pFg5CbB337SQYFKDubR_EQM/
>>>>>>>> 
>>>>>>>> In sec 3.2.1
>>>>>>>> 
>>>>>>>> OLD: SRv6 SID value and put into high order bits of the MPLS
>>>>>>>> Label field.
>>>>>>>> NEW: SRv6 SID value and encoded in the MPLS Label field.
>>>>>>>> 
>>>>>>>> For all occurrences in sections 6.1.1, 6.1.2, 6.2 (two
>>>>>>>> occurrences), 6.2.1, 6.2.2 (two occurrences) and 6.5
>>>>>>>> 
>>>>>>>> OLD: it is set to the Implicit NULL value. In either case, the
>>>>>>>> value is set in the 24 bits (e.g., as 0x000030 in the case of
>>>>>>>> Implicit NULL).
>>>>>>>> NEW: it is set to the Implicit NULL value (i.e., as 0x000030).
>>>>>>>> In either case, the value is set in the 24 bits.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Ketan
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Fri, Jun 17, 2022 at 6:13 AM Alanna Paloma <[e-mail]>
>>>>>>>> wrote:
>>>>>>>> Hi Ketan,
>>>>>>>> 
>>>>>>>> Thank you for your reply. We updated the files as requested and
>>>>>>>> have
>>>>>>>> a couple of follow-up questions.
>>>>>>>> 
>>>>>>>> 1) This suggested text needs further updating as the either/or
>>>>>>>> relationship
>>>>>>>> is not parallel. Please review and let us know if option A or B
>>>>>>>> reflects the
>>>>>>>> intended meaning.
>>>>>>>> 
>>>>>>>> Suggested text:
>>>>>>>> To achieve efficient packing, this document allows 1) the
>>>>>>>> encoding of
>>>>>>>> the SRv6 Service SID as a whole in either the SRv6 Services
>>>>>>>> TLVs, or
>>>>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g.,
>>>>>>>> Locator)
>>>>>>>> in the SRv6 Services TLVs and the encoding of the variable
>>>>>>>> (e.g., Function or Argument parts) in the existing label fields
>>>>>>>> specific to that service encoding.
>>>>>>>> 
>>>>>>>> Perhaps (Moved “either” after allows):
>>>>>>>> A) To achieve efficient packing, this document allows either 1)
>>>>>>>> the encoding of
>>>>>>>> the SRv6 Service SID as a whole in the SRv6 Services TLVs or
>>>>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g.,
>>>>>>>> Locator)
>>>>>>>> in the SRv6 Services TLVs and the encoding of the variable
>>>>>>>> (e.g., Function or Argument parts) in the existing label fields
>>>>>>>> specific to that service encoding.
>>>>>>>> 
>>>>>>>> Or (Removed “either”):
>>>>>>>> B) To achieve efficient packing, this document allows 1) the
>>>>>>>> encoding of
>>>>>>>> the SRv6 Service SID as a whole in the SRv6 Services TLVs or
>>>>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g.,
>>>>>>>> Locator)
>>>>>>>> in the SRv6 Services TLVs and the encoding of the variable
>>>>>>>> (e.g., Function or Argument parts) in the existing label fields
>>>>>>>> specific to that service encoding.
>>>>>>>> 
>>>>>>>> 2) Regarding the terminology, we have not made any changes to
>>>>>>>> the terms
>>>>>>>> where you replied “Depends on the usage”. If any further updates
>>>>>>>> are required
>>>>>>>> for these, please let us know.
>>>>>>>> 
>>>>>>>> The files have been posted here (please refresh):
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.txt
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.html
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf
>>>>>>>> 
>>>>>>>> The relevant diff files have been posted here:
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html
>>>>>>>> (comprehensive diff)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html
>>>>>>>> (AUTH48 changes)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last
>>>>>>>> version to this one)
>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html (last
>>>>>>>> version to this one side by side)
>>>>>>>> 
>>>>>>>> Please review the document carefully and contact us with any
>>>>>>>> further
>>>>>>>> updates you may have. Note that we do not make changes once a
>>>>>>>> document is published as an RFC.
>>>>>>>> 
>>>>>>>> We will await approvals from each author and the AD prior to
>>>>>>>> moving
>>>>>>>> this document forward in the publication process.
>>>>>>>> 
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9252
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> RFC Editor/ap
>>>>>>>> 
>>>>>>>>> On Jun 16, 2022, at 7:55 AM, Ketan Talaulikar
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Alanna,
>>>>>>>>> 
>>>>>>>>> Thanks for resending and please check inline below for
>>>>>>>>> responses.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Thu, Jun 16, 2022 at 6:45 AM Alanna Paloma
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> Hi Ketan,
>>>>>>>>> 
>>>>>>>>> The remaining unanswered queries are listed below.
>>>>>>>>> 
>>>>>>>>> Additionally, they can be seen in the XML file as comments
>>>>>>>>> marked as: <!-- [rfced] ... —>
>>>>>>>>> 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 1) <!--[rfced] We notice that the Abstract and Introduction use
>>>>>>>>> "SRv6-based BGP services" but the title and short title across
>>>>>>>>> the header in the pdf use "SRv6 BGP-based Overlay
>>>>>>>>> Services". Should the titles be updated per Option A or B
>>>>>>>>> below,
>>>>>>>>> or should the text in the Abstract and Introduction be updated
>>>>>>>>> to reflect "SRv6 BGP-based Overlay Services" for consistency?
>>>>>>>>> 
>>>>>>>>> Also note that the abbreviations in the title have been
>>>>>>>>> expanded
>>>>>>>>> per Section 3.6 of RFC 7332 ("RFC Style Guide"). Please review.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> SRv6 BGP based Overlay Services
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> A)
>>>>>>>>> Title: BGP Overlay Services Based on Segment Routing over IPv6
>>>>>>>>> (SRv6)
>>>>>>>>> Short title: SRv6-Based BGP Overlay Services
>>>>>>>>> 
>>>>>>>>> or
>>>>>>>>> 
>>>>>>>>> B)
>>>>>>>>> Title: Segment Routing over IPv6 (SRv6) Overlay Services Based
>>>>>>>>> on BGP
>>>>>>>>> Short Title: SRv6 BGP-Based Overlay Services
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> (A) is more appropriate.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2) <!--[rfced] In this sentence, does "them" refer to
>>>>>>>>> "mechanisms" or "a variable
>>>>>>>>> part"? Please review and let us know how to update.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Section 4 describes mechanisms for signaling of the SRv6
>>>>>>>>> Service SID
>>>>>>>>> by transposing a variable part of the SRv6 SID value and
>>>>>>>>> carrying
>>>>>>>>> them in existing MPLS label fields to achieve more efficient
>>>>>>>>> packing
>>>>>>>>> of those service prefix NLRIs in BGP update messages.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> A) (if referring to "mechanisms"):
>>>>>>>>> Section 4 describes mechanisms for the signaling of the SRv6
>>>>>>>>> Service
>>>>>>>>> SID by transposing a variable part of the SRv6 SID value and
>>>>>>>>> carrying
>>>>>>>>> the mechanism in existing MPLS label fields to achieve more
>>>>>>>>> efficient
>>>>>>>>> packing of those service prefix NLRIs in BGP update messages.
>>>>>>>>> Or
>>>>>>>>> 
>>>>>>>>> B) (if referring to "a variable part"):
>>>>>>>>> Section 4 describes mechanisms for the signaling of the SRv6
>>>>>>>>> Service
>>>>>>>>> SID by transposing a variable part of the SRv6 SID value and
>>>>>>>>> carrying
>>>>>>>>> the variable part in existing MPLS label fields to achieve more
>>>>>>>>> efficient
>>>>>>>>> packing of those service prefix NLRIs in BGP update messages.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> (B) is correct. Wouldn't "and carrying this variable part"
>>>>>>>>> KT> be better?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 3) <!--[rfced] This sentence is a bit tough to read. Please
>>>>>>>>> review the
>>>>>>>>> suggested text and let us know if this is agreeable or if you
>>>>>>>>> prefer otherwise.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> To achieve efficient packing, this document allows the encoding
>>>>>>>>> of
>>>>>>>>> the SRv6 Service SID either as a whole in the SRv6 Services
>>>>>>>>> TLVs or
>>>>>>>>> the encoding of only the common part of the SRv6 SID (e.g.,
>>>>>>>>> Locator)
>>>>>>>>> in the SRv6 Services TLVs and encoding the variable (e.g.,
>>>>>>>>> Function
>>>>>>>>> or Argument parts) in the existing label fields specific to
>>>>>>>>> that
>>>>>>>>> service encoding.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> To achieve efficient packing, this document allows 1) the
>>>>>>>>> encoding of
>>>>>>>>> the SRv6 Service SID as a whole in either the SRv6 Services
>>>>>>>>> TLVs or
>>>>>>>>> the encoding of only the common part of the SRv6 SID (e.g.,
>>>>>>>>> Locator)
>>>>>>>>> in the SRv6 Services TLVs and 2) the encoding of the variable
>>>>>>>>> (e.g., Function or Argument parts) in the existing label
>>>>>>>>> fields
>>>>>>>>> specific to that service encoding.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> KT> I get your point. I think the following conveys the correct
>>>>>>>>> KT> meaning:
>>>>>>>>> 
>>>>>>>>> To achieve efficient packing, this document allows 1) the
>>>>>>>>> encoding of
>>>>>>>>> the SRv6 Service SID as a whole in either the SRv6 Services
>>>>>>>>> TLVs, or
>>>>>>>>> 2) the encoding of only the common part of the SRv6 SID (e.g.,
>>>>>>>>> Locator)
>>>>>>>>> in the SRv6 Services TLVs and the encoding of the variable
>>>>>>>>> (e.g., Function or Argument parts) in the existing label fields
>>>>>>>>> specific to that service encoding.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 5) <!--[rfced] We note that RFC 8950 includes "IPv4 VPN Unicast
>>>>>>>>> over IPv6
>>>>>>>>> Core" and "IPv4 VPN Multicast over IPv6 Core". Is "IPv4 VPN
>>>>>>>>> over
>>>>>>>>> IPv6 Core" okay as is, or should it be updated to reflect
>>>>>>>>> either
>>>>>>>>> of these forms?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> The MP_REACH_NLRI over SRv6 core is encoded according to IPv4
>>>>>>>>> VPN
>>>>>>>>> Over IPv6 Core defined in [RFC8950].
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> A) The MP_REACH_NLRI over SRv6 core is encoded according to
>>>>>>>>> IPv4 VPN
>>>>>>>>> unicast over IPv6 core defined in [RFC8950].
>>>>>>>>> 
>>>>>>>>> Or
>>>>>>>>> 
>>>>>>>>> B) The MP_REACH_NLRI over SRv6 core is encoded according to
>>>>>>>>> IPv4 VPN
>>>>>>>>> multicast over IPv6 core defined in [RFC8950].
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> (A) is correct.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 6) <!--[rfced] The following text mentions where Route Types
>>>>>>>>> 1,2,3,5,6,7,
>>>>>>>>> and 8 are defined, but it does not mention where Route Type 4
>>>>>>>>> is
>>>>>>>>> defined. Is this intentional, or would you like to include a
>>>>>>>>> citation where Route Type 4 is defined? If so, please
>>>>>>>>> provide that reference.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> [RFC7432] defines Route
>>>>>>>>> Types 1, 2, and 3 which carry prefixes and MPLS Label fields;
>>>>>>>>> the
>>>>>>>>> Label fields have a specific use for MPLS encapsulation of EVPN
>>>>>>>>> traffic. Route Type 5 carrying MPLS label information (and thus
>>>>>>>>> encapsulation information) for EVPN is defined in [RFC9136].
>>>>>>>>> Route
>>>>>>>>> Types 6, 7, and 8 are defined in [I-D.ietf-bess-evpn-igmp-mld-
>>>>>>>>> proxy].
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> The Route Type 4 is defined in RFC7432 (https://www.rfc-
>>>>>>>>> KT> editor.org/rfc/rfc7432.html#section-7.4). We don't need to
>>>>>>>>> KT> refer to it and hence citation is also not required. This
>>>>>>>>> KT> is because that route type advertisement is unchanged from
>>>>>>>>> KT> the base spec RFC7432. The original text is therefore
>>>>>>>>> KT> intentional.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 7) <!--[rfced] May we update this sentence from "point-to-point
>>>>>>>>> services ID" to "point-to-point service IDs"?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> EVPN Route Type 1 is also used in EVPN-
>>>>>>>>> VPWS as well as in EVPN flexible cross-connect; mainly used to
>>>>>>>>> advertise point-to-point services ID.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> EVPN Route Type 1 is also used in EVPN-
>>>>>>>>> VPWS as well as in EVPN-flexible cross-connect, mainly to
>>>>>>>>> advertise point-to-point service IDs.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> Ack. Your suggestion above is better than the original.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 8) <!--[rfced] We have included some specific information about
>>>>>>>>> the IANA
>>>>>>>>> text below (mainly FYIs). In addition to reviewing those
>>>>>>>>> changes, please
>>>>>>>>> review all of the IANA-related updates carefully and let us
>>>>>>>>> know
>>>>>>>>> if any further updates are needed.
>>>>>>>>> 
>>>>>>>>> A) FYI: For values 5 and 6, the Type names do not include "TLV"
>>>>>>>>> in the
>>>>>>>>> "BGP Prefix-SID TLV Types" subregistry. We will ask IANA to add
>>>>>>>>> "TLV"
>>>>>>>>> to the subregistry accordingly.
>>>>>>>>> 
>>>>>>>>> Current (Table 1):
>>>>>>>>> | 5 | SRv6 L3 Service TLV | RFC 9252 |
>>>>>>>>> + - - - - - - - - - - - - - - - - - - - - +
>>>>>>>>> | 6 | SRv6 L2 Service TLV | RFC 9252 |
>>>>>>>>> 
>>>>>>>>> Current (IANA registry):
>>>>>>>>> | 5 | SRv6 L3 Service | RFC 9252 |
>>>>>>>>> + - - - - - - - - - - - - - - - - - - - - +
>>>>>>>>> | 6 | SRv6 L2 Service | RFC 9252 |
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> KT> Ack
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> B) FYI: The registration procedures in Tables 2 and 4 do not
>>>>>>>>> match IANA's
>>>>>>>>> registration procedures under the "SRv6 Service Sub-TLV Types"
>>>>>>>>> and
>>>>>>>>> "SRv6 Service Sub-Sub-TLV Types" subregistries. We updated
>>>>>>>>> these
>>>>>>>>> tables to match the registries by changing the "Value" and
>>>>>>>>> "Type"
>>>>>>>>> headings to "Range" and "Registration Procedures",
>>>>>>>>> respectively;
>>>>>>>>> moving the value "0" and its corresponding information to
>>>>>>>>> Tables 3
>>>>>>>>> and 5; and changing "Reserved" to "IETF Review" for value 255.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Value Type
>>>>>>>>> - - - - - - - - - - - - - - - - - -
>>>>>>>>> 0 Reserved
>>>>>>>>> 0-127 IETF Review
>>>>>>>>> 128-254 First Come First Served
>>>>>>>>> 255 Reserved
>>>>>>>>> 
>>>>>>>>> Current (for Tables 2 and 4):
>>>>>>>>> Range Registration Procedures
>>>>>>>>> - - - - - - - - - - - - - - - - - -
>>>>>>>>> 0-127 IETF Review
>>>>>>>>> 128-254 First Come First Served
>>>>>>>>> 255 IETF Review
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> KT> Ack
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> C) FYI: Tables 3 and 5 have been updated to match the
>>>>>>>>> relevant IANA registries. Please review.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> Ack
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 9) <!--[rfced] May we update "SRv6 SID Endpoint" to be "SRv6
>>>>>>>>> Endpoint" to
>>>>>>>>> reflect usage throughout the document?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> The SRv6 SID Endpoint behaviors implementing the services
>>>>>>>>> signalled
>>>>>>>>> in this document are defined in [RFC8986] and hence the
>>>>>>>>> security
>>>>>>>>> considerations of that document apply.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> The SRv6 Endpoint behaviors implementing the services signaled
>>>>>>>>> in this document are defined in [RFC8986]; hence, the security
>>>>>>>>> considerations of that document apply.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> Ack. Your suggested change is better than the original.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 10) <!-- [rfced] FYI: The following reference has been deleted
>>>>>>>>> from the
>>>>>>>>> References section as it was only mentioned within the
>>>>>>>>> Implementation Status section, which has been deleted per your
>>>>>>>>> request.
>>>>>>>>> 
>>>>>>>>> Removed:
>>>>>>>>> [I-D.matsushima-spring-srv6-deployment-status]
>>>>>>>>> Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman,
>>>>>>>>> K., and A. Dhamija, "SRv6 Implementation and Deployment
>>>>>>>>> Status", draft-matsushima-spring-srv6-deployment-status-13
>>>>>>>>> (work in progress), March 2022.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> KT> Ack
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 11) <!--[rfced] Please review the "Inclusive Language" portion
>>>>>>>>> of the
>>>>>>>>> online Style Guide
>>>>>>>>> <https://www.rfc-
>>>>>>>>> editor.org/styleguide/part2/#inclusive_language>
>>>>>>>>> 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> Looks good to me.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 12) <!--[rfced] Throughout the text, the following terminology
>>>>>>>>> appears to be used
>>>>>>>>> inconsistently. Please review these occurrences and let us know
>>>>>>>>> if/how they
>>>>>>>>> may be made consistent.
>>>>>>>>> 
>>>>>>>>> KT> In general, when referring to the name of a field, TLV/sub-
>>>>>>>>> KT> TLV, SID, etc. we have used the capitalized versions. In
>>>>>>>>> KT> other places, as "normal text", there should not be
>>>>>>>>> KT> capitalization.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> - SRv6 Service vs. SRv6 service
>>>>>>>>> 
>>>>>>>>> KT> Depends on the usage
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> - MPLS Label field vs. MPLS label field
>>>>>>>>> 
>>>>>>>>> KT> "MPLS Label field" since we are referring to the name of a
>>>>>>>>> KT> field.
>>>>>>>>> 
>>>>>>>>> - Endpoint Behavior vs. Endpoint behavior vs. endpoint behavior
>>>>>>>>> 
>>>>>>>>> KT> I would think in almost all cases, "Endpoint Behavior"
>>>>>>>>> KT> would be more appropriate - but please correct me.
>>>>>>>>> 
>>>>>>>>> - BGP Service vs. BGP service
>>>>>>>>> 
>>>>>>>>> KT> Depends on the usage
>>>>>>>>> 
>>>>>>>>> - Transposition Offset vs. transposition offset
>>>>>>>>> - Transposition Length vs. transposition length
>>>>>>>>> 
>>>>>>>>> KT> Depends on the usage.
>>>>>>>>> 
>>>>>>>>> - Transposition Scheme vs. transposition scheme
>>>>>>>>> 
>>>>>>>>> KT> The capitalized version was used because we are referring
>>>>>>>>> KT> to the name of the scheme.
>>>>>>>>> 
>>>>>>>>> KT> There is an error in the draft that has been thankfully
>>>>>>>>> KT> caught by a WG participant that we would like to fix.
>>>>>>>>> KT> Please see the thread
>>>>>>>>> KT> here:https://mailarchive.ietf.org/arch/msg/bess/puPdmGwKmmGMJaA_eW_vOM6Bk-
>>>>>>>>> KT> k/
>>>>>>>>> 
>>>>>>>>> The following change is required in the following places:
>>>>>>>>> - 6.1.1 para 2
>>>>>>>>> - 6.1.2 para 2
>>>>>>>>> - 6.2 para 4 and 5
>>>>>>>>> - 6.2.1 para 1
>>>>>>>>> - 6.2.2 para 1 and 2
>>>>>>>>> - 6.5 para 4
>>>>>>>>> 
>>>>>>>>> OLD: the value is set in the high order 20 bits
>>>>>>>>> NEW: the value is set in the 24 bits
>>>>>>>>> 
>>>>>>>>> KT> Additionally, I would like to suggest the following
>>>>>>>>> KT> editorial changes:
>>>>>>>>> 
>>>>>>>>> OLD: [SEGMENT-ROUTING-TE-POLICY]
>>>>>>>>> NEW: If this is going to be replaced by RFC number since it is
>>>>>>>>> also in the RFCed Q, then that is ok. If not, I would suggest
>>>>>>>>> [SEGMENT-ROUTING-POLICY].
>>>>>>>>> 
>>>>>>>>> OLD: [IDR-SEGMENT-ROUTING-TE-POLICY]
>>>>>>>>> NEW: [BGP-SR-POLICY]
>>>>>>>>> 
>>>>>>>>> OLD: [LSR-FLEX-ALGO]
>>>>>>>>> NEW: [IGP-FLEX-ALGO]
>>>>>>>>> 
>>>>>>>>> I am yet to do a full review pass and will do so once these
>>>>>>>>> updates have been incorporated on the full diff against the
>>>>>>>>> original text.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Ketan
>>>>>>>>> 
>>>>>>>>> —>
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> RFC Editor/ap
>>>>>>>>> 
>>>>>>>>>> On Jun 15, 2022, at 11:28 AM, Ketan Talaulikar
>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Alanna,
>>>>>>>>>> 
>>>>>>>>>> For some reason, I am unable to locate your first email (the
>>>>>>>>>> one with the questions?) in my mailbox. Could you please
>>>>>>>>>> resend it?
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Ketan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Jun 15, 2022 at 5:28 AM Alanna Paloma
>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>> Authors and *Andrew (AD),
>>>>>>>>>> 
>>>>>>>>>> *Andrew (AD) - Please review and approve the change from
>>>>>>>>>> “SHOULD” to “MUST” in
>>>>>>>>>> Section 3.1 in the diff file below.
>>>>>>>>>> 
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-ad-diff.html
>>>>>>>>>> 
>>>>>>>>>> Authors - Thank you for your reply. We have updated as
>>>>>>>>>> requested.
>>>>>>>>>> 
>>>>>>>>>> Note that Bruno’s response only answered query 4). Please
>>>>>>>>>> review our previous mail
>>>>>>>>>> (sent on June 10, 2022) to review and respond the the
>>>>>>>>>> remaining queries.
>>>>>>>>>> 
>>>>>>>>>> The files have been posted here (please refresh):
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.txt
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml
>>>>>>>>>> 
>>>>>>>>>> The relevant diff files are posted here:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html
>>>>>>>>>> (comprehensive diff)
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-auth48diff.html
>>>>>>>>>> (all AUTH48 changes)
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastdiff.html
>>>>>>>>>> (htmlwdiff diff between last version and this)
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-lastrfcdiff.html
>>>>>>>>>> (rfcdiff between last version and this)
>>>>>>>>>> 
>>>>>>>>>> Please review the document carefully as documents do not
>>>>>>>>>> change once
>>>>>>>>>> published as RFCs.
>>>>>>>>>> 
>>>>>>>>>> We will await responses to our queries and any further changes
>>>>>>>>>> you may have, as well as
>>>>>>>>>> approvals from each author and the *AD prior to moving forward
>>>>>>>>>> in the publication process.
>>>>>>>>>> 
>>>>>>>>>> Please see the AUTH48 status page for this document here:
>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9252
>>>>>>>>>> 
>>>>>>>>>> Thank you,
>>>>>>>>>> RFC Editor/ap
>>>>>>>>>> 
>>>>>>>>>>> On Jun 13, 2022, at 8:16 AM, [e-mail] wrote:
>>>>>>>>>>> 
>>>>>>>>>>> *Andrew, ADs, Ketan 1rst & 2nd questions are for you. And
>>>>>>>>>>> checking the 3rd would be safer. Thanks.
>>>>>>>>>>> 
>>>>>>>>>>> Hi RFC Editor, all,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for the work.
>>>>>>>>>>> I've reviewed the diff and the full text.
>>>>>>>>>>> Please find below some proposed changes.
>>>>>>>>>>> 
>>>>>>>>>>> ----
>>>>>>>>>>> §3.1
>>>>>>>>>>> In this doc, the semantic of all reserved fields are
>>>>>>>>>>> specified as MUST on the sender side, and MUST on the
>>>>>>>>>>> receiver side. (which is my personal preference, but I ignore
>>>>>>>>>>> if there is an IETF guideline on this) e.g.
>>>>>>>>>>> " RESERVED1 (1 octet):
>>>>>>>>>>> This field MUST be set to 0 by the sender and ignored by the
>>>>>>>>>>> receiver."
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> except the following text which is specified as SHOULD, MUST:
>>>>>>>>>>> 
>>>>>>>>>>> " SRv6 Service SID Flags (1 octet):
>>>>>>>>>>> This field encodes SRv6 Service SID Flags -- none are
>>>>>>>>>>> currently
>>>>>>>>>>> defined. It SHOULD be set to 0 by the sender and any unknown
>>>>>>>>>>> flags MUST be ignored by the receiver."
>>>>>>>>>>> 
>>>>>>>>>>> For consistency in this doc, I would propose
>>>>>>>>>>> OLD: SHOULD
>>>>>>>>>>> NEW: MUST
>>>>>>>>>>> 
>>>>>>>>>>> ----
>>>>>>>>>>> §5
>>>>>>>>>>> " For service over SRv6 core, the egress PE sets the next hop
>>>>>>>>>>> to one of its IPv6 addresses."
>>>>>>>>>>> 
>>>>>>>>>>> May be a personal preference, but I would prefer to make it
>>>>>>>>>>> explicit that "next hop" refers to the BGP Next Hop, as
>>>>>>>>>>> otherwise it would potentially be understood as the
>>>>>>>>>>> forwarding next hop of the egress PE (toward its CE),
>>>>>>>>>>> especially since the long previous paragraph refers to
>>>>>>>>>>> routing tables rather than BGP messages.
>>>>>>>>>>> 
>>>>>>>>>>> OLD: the egress PE sets the next hop
>>>>>>>>>>> NEW: the egress PE sets the BGP Next Hop
>>>>>>>>>>> 
>>>>>>>>>>> (next hop, next-hop, Next-Hop or whatever is usually used
>>>>>>>>>>> equally works for me)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -------
>>>>>>>>>>> 
>>>>>>>>>>> §10.2
>>>>>>>>>>> " [IGMP-MLD-EVPN]
>>>>>>>>>>> Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
>>>>>>>>>>> A., and P. Mattes, "Segment Routing Policy Architecture",
>>>>>>>>>>> Work in Progress, Internet-Draft, draft-ietf-spring-
>>>>>>>>>>> segment-routing-policy-22, 22 March 2022,
>>>>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
>>>>>>>>>>> segment-routing-policy-22>.
>>>>>>>>>>> "
>>>>>>>>>>> 
>>>>>>>>>>> The name of the reference seems (extremely) misleading to me.
>>>>>>>>>>> I would assume a typo
>>>>>>>>>>> OLD: [IGMP-MLD-EVPN]
>>>>>>>>>>> NEW: [SEGMENT-ROUTING-TE-POLICY]
>>>>>>>>>>> 
>>>>>>>>>>> -------
>>>>>>>>>>> 
>>>>>>>>>>> §2
>>>>>>>>>>> " TLV Type (1 octet):
>>>>>>>>>>> This field is assigned values from IANA's "BGP Prefix-SID TLV
>>>>>>>>>>> Types" subregistry."
>>>>>>>>>>> 
>>>>>>>>>>> The field can only contain a single value. So I'd propose
>>>>>>>>>>> 
>>>>>>>>>>> OLD: values
>>>>>>>>>>> NEW: a value
>>>>>>>>>>> 
>>>>>>>>>>> ----
>>>>>>>>>>> "Any unrecognized, received Sub-TLVs and Sub-Sub-TLVs MUST be
>>>>>>>>>>> removed."
>>>>>>>>>>> 
>>>>>>>>>>> Personally I would not put a comma. But English typo is
>>>>>>>>>>> definitely not my expertise. So totally up to you.
>>>>>>>>>>> 
>>>>>>>>>>> ----
>>>>>>>>>>> §3
>>>>>>>>>>> "SRv6 Service Sub-TLV Type (1 octet):
>>>>>>>>>>> This field identifies the type of SRv6 service information.
>>>>>>>>>>> It is
>>>>>>>>>>> assigned values from IANA's "SRv6 Service Sub-TLV Types"
>>>>>>>>>>> subregistry."
>>>>>>>>>>> 
>>>>>>>>>>> The field can only contain a single value. So I'd propose
>>>>>>>>>>> 
>>>>>>>>>>> OLD: values
>>>>>>>>>>> NEW: a value
>>>>>>>>>>> -----
>>>>>>>>>>> 
>>>>>>>>>>> §3.2
>>>>>>>>>>> 
>>>>>>>>>>> SRv6 Service Data Sub-Sub-TLV Type (1 octet):
>>>>>>>>>>> This field identifies the type of Sub-Sub-TLV. It is assigned
>>>>>>>>>>> values from IANA's "SRv6 Service Data Sub-Sub-TLV Types"
>>>>>>>>>>> subregistry.
>>>>>>>>>>> 
>>>>>>>>>>> The field can only contain a single value. So I'd propose
>>>>>>>>>>> 
>>>>>>>>>>> OLD: values
>>>>>>>>>>> NEW: a value
>>>>>>>>>>> 
>>>>>>>>>>> ----
>>>>>>>>>>> §3.2.1
>>>>>>>>>>> 
>>>>>>>>>>> " While for an SRv6
>>>>>>>>>>> SID, where the FL is 24 bits and only the lower order 20 bits
>>>>>>>>>>> are
>>>>>>>>>>> transposed (e.g., due to the limit of the MPLS label field
>>>>>>>>>>> size), the
>>>>>>>>>>> transposition offset is set to 68 and the transposition
>>>>>>>>>>> length is set
>>>>>>>>>>> to 20."
>>>>>>>>>>> 
>>>>>>>>>>> I would not put the first comma. And I could rather use "for
>>>>>>>>>>> which" rather than "where"
>>>>>>>>>>> OLD: While for an SRv6 SID, where the FL is 24 bits
>>>>>>>>>>> NEW: While for an SRv6SID for which the FL is 24 bits
>>>>>>>>>>> 
>>>>>>>>>>> However English is not my first language, so totally up to
>>>>>>>>>>> you.
>>>>>>>>>>> 
>>>>>>>>>>> -----
>>>>>>>>>>> §5
>>>>>>>>>>> 
>>>>>>>>>>> OLD: When the BGP route is received at an ingress PE is
>>>>>>>>>>> colored with a
>>>>>>>>>>> Color Extended Community and a valid SRv6 Policy is
>>>>>>>>>>> available, the
>>>>>>>>>>> steering for service flows is performed, as described in
>>>>>>>>>>> Section 8
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> NEW: When the BGP route received at an ingress PE is colored
>>>>>>>>>>> with a
>>>>>>>>>>> Color Extended Community and a valid SRv6 Policy is
>>>>>>>>>>> available, the
>>>>>>>>>>> steering for service flows is performed as described in
>>>>>>>>>>> Section 8
>>>>>>>>>>> 
>>>>>>>>>>> i.e.
>>>>>>>>>>> :s/is received/received
>>>>>>>>>>> :s/is performed, as described/ is performed as described
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> §6
>>>>>>>>>>> 
>>>>>>>>>>> Idem above. (except that the 2nd correction is already in
>>>>>>>>>>> place)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Regards,
>>>>>>>>>>> --Bruno
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Orange Restricted
>>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: [e-mail] <[e-mail]>
>>>>>>>>>>> Sent: Friday, June 10, 2022 10:56 PM
>>>>>>>>>>> To: [e-mail]; [e-mail];
>>>>>>>>>>> [e-mail]; DECRAENE Bruno INNOV/NET
>>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>> [e-mail];[e-mail]
>>>>>>>>>>> Cc: [e-mail]; [e-mail]; bess-
>>>>>>>>>>> [e-mail]; [e-mail]; andrew-
>>>>>>>>>>> [e-mail]; [e-mail]
>>>>>>>>>>> Subject: AUTH48: RFC-to-be 9252 <draft-ietf-bess-srv6-
>>>>>>>>>>> services-15> for your review
>>>>>>>>>>> 
>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>> 
>>>>>>>>>>> Updated 2022/06/10
>>>>>>>>>>> 
>>>>>>>>>>> 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://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
>>>>>>>>>>> 
>>>>>>>>>>> * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-
>>>>>>>>>>> 4Q9l2USxIAe6P8O4Zc
>>>>>>>>>>> 
>>>>>>>>>>> * The archive itself:
>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>>> 
>>>>>>>>>>> * 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 CC’ed on this message need to see your
>>>>>>>>>>> approval.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Files
>>>>>>>>>>> -----
>>>>>>>>>>> 
>>>>>>>>>>> The files are available here:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.xml
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.pdf
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.txt
>>>>>>>>>>> 
>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-rfcdiff.html (side
>>>>>>>>>>> by side)
>>>>>>>>>>> 
>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252-xmldiff1.html
>>>>>>>>>>> 
>>>>>>>>>>> The following files are provided to facilitate creation of
>>>>>>>>>>> your own
>>>>>>>>>>> diff files of the XML.
>>>>>>>>>>> 
>>>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.original.v2v3.xml
>>>>>>>>>>> 
>>>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format
>>>>>>>>>>> updates
>>>>>>>>>>> only:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9252.form.xml
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Tracking progress
>>>>>>>>>>> -----------------
>>>>>>>>>>> 
>>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9252
>>>>>>>>>>> 
>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>> 
>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>> 
>>>>>>>>>>> RFC Editor
>>>>>>>>>>> 
>>>>>>>>>>> --------------------------------------
>>>>>>>>>>> RFC9252 (draft-ietf-bess-srv6-services-15)
>>>>>>>>>>> 
>>>>>>>>>>> Title : SRv6 BGP based Overlay Services
>>>>>>>>>>> Author(s) : G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B.
>>>>>>>>>>> Decraene, S. Zhuang, J. Rabadan
>>>>>>>>>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski
>>>>>>>>>>> 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.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _________________________________________________________________________________________________________________________
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
> 
>