Greetings all, Thank you for confirming that this document should move forward with RFC-to-be 9857. RFC-to-be 9857 has now completed AUTH48, so we will begin preparing both documents for publication at this time.
All best, Kaelin Foody RFC Production Center > On Oct 28, 2025, at 12:27 AM, Ketan Talaulikar <[email protected]> wrote: > > Hi Kaelin, > > RFC-to-be 9857 is now ready and you may follow-up with Karen who is working > on that document. > > Thanks, > Ketan > > On Mon, Oct 27, 2025 at 7:41 PM Mike Koldychev <[email protected]> wrote: > I'm also good with waiting. > > Thanks, > Mike. > > On Monday, October 27th, 2025 at 3:55 AM, Samuel Sidor (ssidor) > <[email protected]> wrote: >> Hi Kaelin, Ketan, >> >> Sorry for delay, I was off on Friday. >> >> I’m fine with waiting for RFC-to-be 9857. >> >> Regards, >> Samuel >> >> From: Ketan Talaulikar <[email protected]> >> Date: Monday, 27 October 2025 at 07:17 >> To: Kaelin Foody <[email protected]> >> Cc: Samuel Sidor (ssidor) <[email protected]>, [email protected] >> <[email protected]>, [email protected] <[email protected]>, >> [email protected] <[email protected]>, [email protected] >> <[email protected]>, [email protected] <[email protected]>, >> [email protected] <[email protected]>, [email protected] >> <[email protected]>, [email protected] <[email protected]>, >> [email protected] <[email protected]>, [email protected] >> <[email protected]>, [email protected] >> <[email protected]> >> Subject: Re: AUTH48: RFC-to-be 9862 >> <draft-ietf-pce-segment-routing-policy-cp-27> for your review >> >> Hi Kaelin, >> >> I would suggest holding this document so that it goes with the reference of >> RFC-to-be 9857. I've dropped a reminder to John (AD for that document) and >> hopefully we should be able to get that going soonish. >> >> Thanks, >> Ketan >> >> >> On Fri, Oct 24, 2025 at 12:56 AM Kaelin Foody <[email protected]> >> wrote: >> Authors, >> >> While preparing this document for publication, we noticed that this document >> informatively references RFC-to-be 9857, which is currently in AUTH48 state. >> RFC-to-be 9857 is awaiting approvals from IANA and the responsible AD; once >> we receive those, it will move to publication. >> >> Would you like us to wait until RFC-to-be 9857 is published before >> proceeding with the publication of this document? >> >> Please let us know what you prefer when you get the chance. >> >> All the best, >> >> Kaelin Foody >> RFC Production Center >> >> > On Oct 22, 2025, at 11:20 AM, Kaelin Foody <[email protected]> >> > wrote: >> > >> > Greetings all, >> > >> > Thanks for the updates, Sabrina! They look great. >> > >> > We have now received all necessary approvals and will move this document >> > forward in the publication process at this time. >> > >> > The AUTH48 status page of this document is available at >> > http://www.rfc-editor.org/auth48/rfc9862. >> > >> > Thank you all for your time and attention during AUTH48. >> > >> > All best, >> > >> > Kaelin Foody >> > RFC Production Center >> > >> >> On Oct 21, 2025, at 7:51 PM, Sabrina Tanamal via RT >> >> <[email protected]> wrote: >> >> >> >> Hi Kaelin, >> >> >> >> These changes are complete: >> >> >> >> https://www.iana.org/assignments/pcep >> >> >> >> Thanks, >> >> Sabrina >> >> >> >> On Tue Oct 21 21:12:14 2025, [email protected] wrote: >> >>> IANA, >> >>> >> >>> Please make the following updates to the "Path Computation Element >> >>> Protocol (PCEP) Numbers” registry at >> >>> <https://www.iana.org/assignments/pcep/pcep.xhtml>. >> >>> >> >>> >> >>> 1.) Please add “TLV" to the item below in >> >>> <https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object>. >> >>> >> >>> OLD: >> >>> 10 Reception of an invalid object >> >>> 44: Missing SRPOLICY-CAPABILITY >> >>> >> >>> NEW: >> >>> 10 Reception of an invalid object >> >>> 44: Missing SRPOLICY-CAPABILITY TLV >> >>> >> >>> >> >>> 2.) Please update these two items as follows at these registries: >> >>> >> >>> <https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy- >> >>> invalidation-operational-flags> >> >>> <https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy- >> >>> invalidation-configuration-flags> >> >>> >> >>> OLD: >> >>> 7 D: dropping - the LSP is currently attracting traffic and actively >> >>> dropping it. >> >>> >> >>> 7 D: drop enabled - the Drop-upon-invalid is enabled on the LSP. >> >>> >> >>> NEW: >> >>> 7 D: Dropping - the LSP is actively dropping traffic as a result of >> >>> Drop-Upon-Invalid behavior being activated. >> >>> >> >>> 7 D: Drop enabled - the Candidate Path has Drop-Upon-Invalid feature >> >>> enabled. >> >>> >> >>> >> >>> 3.) Please lowercase the “f” in “Flag” for the following items at >> >>> <https://www.iana.org/assignments/pcep/pcep.xhtml#sr-policy- >> >>> capability-tlv-flag-field>. >> >>> >> >>> OLD: >> >>> 27 Stateless Operation (L-Flag) >> >>> 29 Invalidation (I-Flag) >> >>> 30 Explicit NULL Label Policy (E-Flag) >> >>> >> >>> NEW: >> >>> 27 Stateless Operation (L-flag) >> >>> 29 Invalidation (I-flag) >> >>> 30 Explicit NULL Label Policy (E-flag) >> >>> >> >>> >> >>> Thank you! >> >>> >> >>> Kaelin Foody >> >>> RFC Production Center >> >>> >> >>>> On Oct 21, 2025, at 1:45 PM, Hooman Bidgoli (Nokia) >> >>>> <[email protected]> wrote: >> >>>> >> >>>> Sorry for delay >> >>>> >> >>>> Approved >> >>>> >> >>>> Thanks >> >>>> Hooman >> >>>> >> >>>> -----Original Message----- >> >>>> From: Kaelin Foody <[email protected]> >> >>>> Sent: Monday, October 20, 2025 9:16 AM >> >>>> To: Colby Barth <[email protected]> >> >>>> Cc: Pengshuping (Peng Shuping) <[email protected]>; Sivabalan, >> >>>> Siva <[email protected]>; Mike Koldychev <[email protected]>; >> >>>> Samuel Sidor (ssidor) <[email protected]>; Roman Danyliw >> >>>> <[email protected]>; [email protected]; Hooman Bidgoli (Nokia) >> >>>> <[email protected]>; [email protected]; Dhruv Dhody >> >>>> <[email protected]>; [email protected]; auth48archive@rfc- >> >>>> editor.org >> >>>> Subject: Re: AUTH48: RFC-to-be 9862 <draft-ietf-pce-segment-routing- >> >>>> policy-cp-27> for your review >> >>>> >> >>>> >> >>>> CAUTION: This is an external email. Please be very careful when >> >>>> clicking links or opening attachments. See the URL nok.it/ext for >> >>>> additional information. >> >>>> >> >>>> >> >>>> >> >>>> Colby, Shuping, Siva, Mike, all, >> >>>> >> >>>> Thank you for your approvals! We have marked them on the AUTH48 >> >>>> status page for this document. >> >>>> >> >>>> The AUTH48 status page for this document is available here: >> >>>> http://www.rfc-editor.org/auth48/rfc9862. >> >>>> >> >>>> We now only await Hooman Bidgoli’s approval before moving this >> >>>> document forward in the publication process. >> >>>> >> >>>> Thank you, >> >>>> >> >>>> Kaelin Foody >> >>>> RFC Production Center >> >>>> >> >>>>> On Oct 19, 2025, at 8:32 AM, Colby Barth <[email protected]> wrote: >> >>>>> >> >>>>> I approve. >> >>>>> >> >>>>> Thanks, >> >>>>> >> >>>>> —Colby >> >>>>> >> >>>>> >> >>>>> Juniper Business Use Only >> >>>>> From: Pengshuping (Peng Shuping) <[email protected]> >> >>>>> Date: Friday, October 17, 2025 at 7:03 AM >> >>>>> To: Sivabalan, Siva <[email protected]>, Mike Koldychev >> >>>>> <[email protected]>, Kaelin Foody <[email protected]> >> >>>>> Cc: Samuel Sidor (ssidor) <[email protected]>, Roman Danyliw >> >>>>> <[email protected]>, [email protected] <rfc-editor@rfc- >> >>>>> editor.org>, Colby Barth <[email protected]>, >> >>>>> [email protected] <[email protected]>, pce- >> >>>>> [email protected] <[email protected]>, Dhruv Dhody <[email protected]>, >> >>>>> [email protected] <[email protected]>, auth48archive@rfc- >> >>>>> editor.org <[email protected]> >> >>>>> Subject: RE: [**EXTERNAL**] Re: AUTH48: RFC-to-be 9862 <draft-ietf- >> >>>>> pce-segment-routing-policy-cp-27> for your review >> >>>>> >> >>>>> [External Email. Be cautious of content] >> >>>>> >> >>>>> >> >>>>> I approve the publication. >> >>>>> >> >>>>> Thanks, >> >>>>> Shuping >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Sivabalan, Siva <[email protected]> >> >>>>> Sent: Saturday, October 11, 2025 10:44 PM >> >>>>> To: Mike Koldychev <[email protected]>; Kaelin Foody >> >>>>> <[email protected]> >> >>>>> Cc: Samuel Sidor (ssidor) <[email protected]>; Roman Danyliw >> >>>>> <[email protected]>; [email protected]; [email protected]; >> >>>>> Pengshuping (Peng Shuping) <[email protected]>; >> >>>>> [email protected]; [email protected]; Dhruv Dhody >> >>>>> <[email protected]>; [email protected]; auth48archive@rfc- >> >>>>> editor.org >> >>>>> Subject: RE: [**EXTERNAL**] Re: AUTH48: RFC-to-be 9862 <draft-ietf- >> >>>>> pce-segment-routing-policy-cp-27> for your review >> >>>>> >> >>>>> I approve the publication. >> >>>>> >> >>>>> Thanks, >> >>>>> Siva >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Mike Koldychev <[email protected]> >> >>>>> Sent: Friday, October 10, 2025 3:03 PM >> >>>>> To: Kaelin Foody <[email protected]> >> >>>>> Cc: Samuel Sidor (ssidor) <[email protected]>; Roman Danyliw >> >>>>> <[email protected]>; [email protected]; Sivabalan, Siva >> >>>>> <[email protected]>; [email protected]; [email protected]; >> >>>>> [email protected]; [email protected]; Dhruv Dhody >> >>>>> <[email protected]>; [email protected]; auth48archive@rfc- >> >>>>> editor.org >> >>>>> Subject: [**EXTERNAL**] Re: AUTH48: RFC-to-be 9862 <draft-ietf-pce- >> >>>>> segment-routing-policy-cp-27> for your review >> >>>>> >> >>>>> Hi Kaelin, >> >>>>> >> >>>>> I approve the publication. >> >>>>> >> >>>>> Thanks, >> >>>>> Mike. >> >>>>> >> >>>>> On Thursday, October 9th, 2025 at 9:49 AM, Kaelin Foody >> >>>>> <[email protected]> wrote: >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> Authors, >> >>>>>> >> >>>>>> This is a friendly reminder that we await some of your approvals >> >>>>>> regarding this document’s readiness for publication. We will await >> >>>>>> approvals >> >>>>>> from each author listed on the AUTH48 status page prior to moving >> >>>>>> this document forward in the publication process. >> >>>>>> >> >>>>>> The AUTH48 status page for this document is available here: >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/auth48/rfc9862__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLW4CdYiQ$ [rfc-editor[.]org] >> >>>>>> >> >>>>>> Upon careful review, please contact us with any further updates or >> >>>>>> with your approval of the document in its current form. >> >>>>>> >> >>>>>> Please review the document carefully to ensure satisfaction as we >> >>>>>> do not make changes once it has been published as an RFC. >> >>>>>> >> >>>>>> — FILES (please refresh): — >> >>>>>> >> >>>>>> The updated files have been posted here: >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862.txt__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUD2iauT$ [rfc-editor[.]org] >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862.pdf__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLS4fEcvY$ [rfc-editor[.]org] >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLU3OXvQT$ [rfc-editor[.]org] >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862.xml__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUR6Qve7$ [rfc-editor[.]org] >> >>>>>> >> >>>>>> The relevant diff files have been posted here: >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862- >> >>>>>> auth48diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLa64r9iz$ [rfc-editor[.]org] >> >>>>>> (AUTH48 changes only) >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862- >> >>>>>> auth48rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLStiXoII$ [rfc-editor[.]org] (AUTH >> >>>>>> 48 changes side by side) >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862- >> >>>>>> diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWkkQJ2v$ [rfc-editor[.]org] (all >> >>>>>> changes) >> >>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>> editor.org/authors/rfc9862- >> >>>>>> rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWA0wzhO$ [rfc-editor[.]org] (all >> >>>>>> changes side by side) >> >>>>>> >> >>>>>> Thank you, >> >>>>>> >> >>>>>> Kaelin Foody >> >>>>>> RFC Production Center >> >>>>>> >> >>>>>>> On Oct 3, 2025, at 3:07 PM, Kaelin Foody [email protected] >> >>>>>>> editor.org wrote: >> >>>>>>> >> >>>>>>> Hi Dhruv, Samuel, all, >> >>>>>>> >> >>>>>>> Dhruv - Thanks for your reply and request. We have condensed the >> >>>>>>> two tables in Section 6.3 into one and removed the duplicate lead- >> >>>>>>> in text. You may view these updates in the diff: >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862- >> >>>>>>> auth48rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLStiXoII$ [rfc-editor[.]org]. >> >>>>>>> >> >>>>>>> Samuel - Thanks for your approval; we have marked it on the AUTH48 >> >>>>>>> status page for this document. >> >>>>>>> >> >>>>>>> We await approvals from each author listed on the AUTH48 status >> >>>>>>> page prior to moving forward in the publication process. >> >>>>>>> >> >>>>>>> The AUTH48 status page for this document is available here: >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/auth48/rfc9862__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLW4CdYiQ$ [rfc-editor[.]org] >> >>>>>>> >> >>>>>>> — FILES (please refresh): — >> >>>>>>> >> >>>>>>> The updated files have been posted here: >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862.txt__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUD2iauT$ [rfc-editor[.]org] >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862.pdf__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLS4fEcvY$ [rfc-editor[.]org] >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLU3OXvQT$ [rfc-editor[.]org] >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862.xml__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUR6Qve7$ [rfc-editor[.]org] >> >>>>>>> >> >>>>>>> The relevant diff files have been posted here: >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862- >> >>>>>>> auth48diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLa64r9iz$ [rfc-editor[.]org] >> >>>>>>> (AUTH48 changes only) >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862- >> >>>>>>> auth48rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLStiXoII$ [rfc-editor[.]org] (AUTH >> >>>>>>> 48 changes side by side) >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862- >> >>>>>>> diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWkkQJ2v$ [rfc-editor[.]org] (all >> >>>>>>> changes) >> >>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>> editor.org/authors/rfc9862- >> >>>>>>> rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWA0wzhO$ [rfc-editor[.]org] (all >> >>>>>>> changes side by side) >> >>>>>>> >> >>>>>>> Thanks for your time, >> >>>>>>> >> >>>>>>> Kaelin Foody >> >>>>>>> RFC Production Center >> >>>>>>> >> >>>>>>>> On Oct 1, 2025, at 12:15 AM, Dhruv Dhody [email protected] wrote: >> >>>>>>>> >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>> Just one comment on section 6.3 - >> >>>>>>>> >> >>>>>>>> The two tables made sense in the draft as we were giving two >> >>>>>>>> distinct instructions to IANA - (1) to confirm existing >> >>>>>>>> allocations and (2) for new allocations at >> >>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- >> >>>>>>>> ietf-pce-segment-routing-policy-cp-27*section- >> >>>>>>>> 6.3__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLeNs0Nbn$ >> >>>>>>>> [datatracker[.]ietf[.]org] >> >>>>>>>> >> >>>>>>>> In the published RFC, this distinction does not make sense and I >> >>>>>>>> suggest we can have a single table now at >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862.html*section- >> >>>>>>>> 6.3__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLTLoSiOd$ [rfc-editor[.]org] and >> >>>>>>>> update the initial list accordingly. >> >>>>>>>> >> >>>>>>>> Thanks! >> >>>>>>>> Dhruv >> >>>>>>>> >> >>>>>>>> On Tue, Sep 30, 2025 at 10:36 PM Samuel Sidor (ssidor) >> >>>>>>>> [email protected] wrote: >> >>>>>>>> Thanks a lot, Kaelin. >> >>>>>>>> >> >>>>>>>> Looks fine to me, so approving from my side. >> >>>>>>>> >> >>>>>>>> Regards, >> >>>>>>>> Samuel >> >>>>>>>> >> >>>>>>>> From: Kaelin Foody [email protected] >> >>>>>>>> Date: Tuesday, 30 September 2025 at 18:18 >> >>>>>>>> To: Samuel Sidor (ssidor) [email protected] >> >>>>>>>> Cc: Roman Danyliw [email protected], [email protected] rfc- >> >>>>>>>> [email protected], [email protected] [email protected], >> >>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>> [email protected], [email protected] >> >>>>>>>> [email protected], [email protected] >> >>>>>>>> [email protected], [email protected] [email protected], pce- >> >>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>> [email protected], [email protected] >> >>>>>>>> [email protected] >> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9862 <draft-ietf-pce-segment- >> >>>>>>>> routing-policy-cp-27> for your review >> >>>>>>>> >> >>>>>>>> Hi Samuel, >> >>>>>>>> >> >>>>>>>> We have updated several instances in Sections 5.1 and 5.2.2 to >> >>>>>>>> "EXPLICIT-NULL-LABEL-POLICY TLV" per your request. Please review >> >>>>>>>> and let us know if any further updates are needed. >> >>>>>>>> >> >>>>>>>> Upon careful review, please contact us with any further updates >> >>>>>>>> or with your approval of the document in its current form. We >> >>>>>>>> will await approvals from each author listed on the AUTH48 status >> >>>>>>>> page prior to moving forward in the publication process. >> >>>>>>>> >> >>>>>>>> The AUTH48 status page for this document is available here: >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/auth48/rfc9862__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLW4CdYiQ$ [rfc-editor[.]org] >> >>>>>>>> >> >>>>>>>> Please review the document carefully to ensure satisfaction as we >> >>>>>>>> do not make changes once it has been published as an RFC. >> >>>>>>>> >> >>>>>>>> — FILES (please refresh): — >> >>>>>>>> >> >>>>>>>> The updated files have been posted here: >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862.txt__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUD2iauT$ [rfc-editor[.]org] >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862.pdf__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLS4fEcvY$ [rfc-editor[.]org] >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLU3OXvQT$ [rfc-editor[.]org] >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862.xml__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUR6Qve7$ [rfc-editor[.]org] >> >>>>>>>> >> >>>>>>>> The relevant diff files have been posted here: >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>> auth48diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLa64r9iz$ [rfc-editor[.]org] >> >>>>>>>> (AUTH48 changes only) >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>> auth48rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLStiXoII$ [rfc-editor[.]org] >> >>>>>>>> (AUTH 48 changes side by side) >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>> diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWkkQJ2v$ [rfc-editor[.]org] (all >> >>>>>>>> changes) >> >>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>> rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWA0wzhO$ [rfc-editor[.]org] (all >> >>>>>>>> changes side by side) >> >>>>>>>> >> >>>>>>>> Thank you, >> >>>>>>>> >> >>>>>>>> Kaelin Foody >> >>>>>>>> RFC Production Center >> >>>>>>>> >> >>>>>>>>> On Sep 30, 2025, at 10:23 AM, Samuel Sidor (ssidor) >> >>>>>>>>> [email protected] wrote: >> >>>>>>>>> >> >>>>>>>>> Hi Kaelin, >> >>>>>>>>> >> >>>>>>>>> Thanks a lot for renaming "Explicit Null Label Policy TLV" to >> >>>>>>>>> "EXPLICIT-NULL-LABEL-POLICY TLV”. >> >>>>>>>>> >> >>>>>>>>> It seems that there are still 3 remaining occurrences of old >> >>>>>>>>> name: >> >>>>>>>>> >> >>>>>>>>> • Description of E-flag in Section 5.1 >> >>>>>>>>> >> >>>>>>>>> E-flag (Explicit NULL Label Policy): If set to 1 by a PCEP >> >>>>>>>>> speaker, the E-flag indicates that the PCEP speaker supports the >> >>>>>>>>> handling of the Explicit NULL Label Policy (ENLP) TLV for the SR >> >>>>>>>>> Policy (Section 5.2.2). If this flag is set to 0, then the >> >>>>>>>>> receiving PCEP speaker MUST NOT send the ENLP TLV and MUST >> >>>>>>>>> ignore it on receipt. >> >>>>>>>>> • “Figure 8: Explicit NULL Label Policy (ENLP) TLV Format” in >> >>>>>>>>> Section 5.2.2 >> >>>>>>>>> • In section 5.2.2 we are referring to ENLP TLV, but since name >> >>>>>>>>> of that TLV was updated, we are not introducing “ENLP TLV” >> >>>>>>>>> anywhere, so I assume that we will need to replace those 2 >> >>>>>>>>> occurrences with complete TLV name. >> >>>>>>>>> >> >>>>>>>>> Can we update those as well? Besides that the document looks >> >>>>>>>>> fine to me. >> >>>>>>>>> >> >>>>>>>>> Thanks a lot, >> >>>>>>>>> Samuel >> >>>>>>>>> >> >>>>>>>>> From: Kaelin Foody [email protected] >> >>>>>>>>> Date: Tuesday, 30 September 2025 at 16:02 >> >>>>>>>>> To: Samuel Sidor (ssidor) [email protected] >> >>>>>>>>> Cc: Roman Danyliw [email protected], [email protected] rfc- >> >>>>>>>>> [email protected], [email protected] [email protected], >> >>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>> [email protected], [email protected] >> >>>>>>>>> [email protected], [email protected] >> >>>>>>>>> [email protected], [email protected] [email protected], >> >>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>> [email protected], [email protected] >> >>>>>>>>> [email protected] >> >>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9862 <draft-ietf-pce-segment- >> >>>>>>>>> routing-policy-cp-27> for your review >> >>>>>>>>> >> >>>>>>>>> Hi all, >> >>>>>>>>> >> >>>>>>>>> Roman - Thank you for your reply and approval. We have marked >> >>>>>>>>> your approval as AD on the AUTH48 status page. >> >>>>>>>>> >> >>>>>>>>> Samuel - Thank you for your response. We have updated 2 >> >>>>>>>>> instances of "Explicit Null Label Policy TLV" to "EXPLICIT-NULL- >> >>>>>>>>> LABEL-POLICY TLV” (in the title of 5.2.2 and one instance in >> >>>>>>>>> Section 5.2.2) to match Table 2. Please review and let us know >> >>>>>>>>> if any further changes are needed. >> >>>>>>>>> >> >>>>>>>>> We will await approvals from each author listed on the AUTH48 >> >>>>>>>>> status page prior to moving forward in the publication process. >> >>>>>>>>> >> >>>>>>>>> The AUTH48 status page for this document is available here: >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/auth48/rfc9862__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLW4CdYiQ$ [rfc-editor[.]org] >> >>>>>>>>> >> >>>>>>>>> Please review the document carefully to ensure satisfaction as >> >>>>>>>>> we do not make changes once it has been published as an RFC. >> >>>>>>>>> >> >>>>>>>>> — FILES (please refresh): — >> >>>>>>>>> >> >>>>>>>>> The updated files have been posted here: >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862.txt__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUD2iauT$ [rfc-editor[.]org] >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862.pdf__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLS4fEcvY$ [rfc-editor[.]org] >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLU3OXvQT$ [rfc-editor[.]org] >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862.xml__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUR6Qve7$ [rfc-editor[.]org] >> >>>>>>>>> >> >>>>>>>>> The relevant diff files have been posted here: >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>> auth48diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLa64r9iz$ [rfc-editor[.]org] >> >>>>>>>>> (AUTH48 changes only) >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>> auth48rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLStiXoII$ [rfc-editor[.]org] >> >>>>>>>>> (AUTH 48 changes side by side) >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>> diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWkkQJ2v$ [rfc-editor[.]org] >> >>>>>>>>> (all changes) >> >>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>> rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWA0wzhO$ [rfc-editor[.]org] >> >>>>>>>>> (all changes side by side) >> >>>>>>>>> >> >>>>>>>>> Thank you, >> >>>>>>>>> >> >>>>>>>>> Kaelin Foody >> >>>>>>>>> RFC Production Center >> >>>>>>>>> >> >>>>>>>>>> On Sep 29, 2025, at 4:28 AM, Samuel Sidor (ssidor) >> >>>>>>>>>> [email protected] wrote: >> >>>>>>>>>> >> >>>>>>>>>> Hi Kaelin, >> >>>>>>>>>> >> >>>>>>>>>> Changes looks great to me. >> >>>>>>>>>> >> >>>>>>>>>> One small nit/question: >> >>>>>>>>>> >> >>>>>>>>>> In Section 5.2.2, section is called “Explicit NULL Label Policy >> >>>>>>>>>> (ENLP) TLV”, but in 6.2.2 we are still calling it “EXPLICIT- >> >>>>>>>>>> NULL-LABEL-POLICY”. Is the intentional? >> >>>>>>>>>> >> >>>>>>>>>> Thanks a lot, >> >>>>>>>>>> Samuel >> >>>>>>>>>> >> >>>>>>>>>> From: Roman Danyliw [email protected] >> >>>>>>>>>> Date: Saturday, 27 September 2025 at 00:34 >> >>>>>>>>>> To: Kaelin Foody [email protected], Samuel Sidor >> >>>>>>>>>> (ssidor) [email protected] >> >>>>>>>>>> Cc: [email protected] [email protected], >> >>>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>>> [email protected], [email protected] [email protected], >> >>>>>>>>>> [email protected] [email protected], >> >>>>>>>>>> [email protected] [email protected], pce- >> >>>>>>>>>> [email protected] [email protected], [email protected] pce- >> >>>>>>>>>> [email protected], [email protected] [email protected], >> >>>>>>>>>> [email protected] [email protected] >> >>>>>>>>>> Subject: RE: [AD] Re: AUTH48: RFC-to-be 9862 <draft-ietf-pce- >> >>>>>>>>>> segment-routing-policy-cp-27> for your review >> >>>>>>>>>> >> >>>>>>>>>> Approved. >> >>>>>>>>>> >> >>>>>>>>>> -----Original Message----- >> >>>>>>>>>> From: Kaelin Foody [email protected] >> >>>>>>>>>> Sent: Friday, September 26, 2025 6:01 PM >> >>>>>>>>>> To: Samuel Sidor (ssidor) [email protected]; >> >>>>>>>>>> Roman Danyliw [email protected] >> >>>>>>>>>> Cc: [email protected]; [email protected]; >> >>>>>>>>>> [email protected]; [email protected]; [email protected]; >> >>>>>>>>>> [email protected]; [email protected]; pce- >> >>>>>>>>>> [email protected]; [email protected]; Roman Danyliw [email protected]; >> >>>>>>>>>> [email protected] >> >>>>>>>>>> Subject: [AD] Re: AUTH48: RFC-to-be 9862 <draft-ietf-pce- >> >>>>>>>>>> segment-routing-policy-cp-27> for your review >> >>>>>>>>>> >> >>>>>>>>>> Warning: External Sender - do not click links or open >> >>>>>>>>>> attachments unless you recognize the sender and know the >> >>>>>>>>>> content is safe. >> >>>>>>>>>> >> >>>>>>>>>> Hi Samuel and *Roman, >> >>>>>>>>>> >> >>>>>>>>>> * Roman - As AD, please review the following changes in >> >>>>>>>>>> Sections 4.4, 6.5, and 6.6 and let us know if you approve. The >> >>>>>>>>>> updates can be viewed here: >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>> auth48diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLa64r9iz$ [rfc-editor[.]org]. >> >>>>>>>>>> >> >>>>>>>>>> a) Section 4.4 (addition of “shortest” below): >> >>>>>>>>>> >> >>>>>>>>>> OLD: >> >>>>>>>>>> >> >>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>> reaching the Endpoint and have decapsulated traffic be >> >>>>>>>>>> forwarded the rest of the path to the Endpoint node using the >> >>>>>>>>>> native Interior Gateway Protocol >> >>>>>>>>>> (IGP) path(s). >> >>>>>>>>>> >> >>>>>>>>>> NEW: >> >>>>>>>>>> >> >>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>> reaching the Endpoint and have decapsulated traffic be >> >>>>>>>>>> forwarded the rest of the path to the Endpoint node using the >> >>>>>>>>>> Interior Gateway Protocol (IGP) shortest path(s). >> >>>>>>>>>> >> >>>>>>>>>> b) Sections 6.5 and 6.6 (updates to the definitions in the IANA >> >>>>>>>>>> Considerations section): >> >>>>>>>>>> >> >>>>>>>>>> OLD: >> >>>>>>>>>> >> >>>>>>>>>> D: dropping - the LSP is currently attracting traffic and >> >>>>>>>>>> actively dropping it. >> >>>>>>>>>> >> >>>>>>>>>> D: drop enabled - the Drop-upon-invalid is enabled on the LSP. >> >>>>>>>>>> >> >>>>>>>>>> NEW: >> >>>>>>>>>> >> >>>>>>>>>> D: Dropping - the LSP is actively dropping traffic as a result >> >>>>>>>>>> of Drop-Upon-Invalid behavior being activated. >> >>>>>>>>>> >> >>>>>>>>>> D: Drop enabled - the Candidate Path has Drop-Upon-Invalid >> >>>>>>>>>> feature enabled. >> >>>>>>>>>> >> >>>>>>>>>> Samuel - Thank you for your reply; we have updated the document >> >>>>>>>>>> accordingly. >> >>>>>>>>>> >> >>>>>>>>>> A few follow-up notes: >> >>>>>>>>>> >> >>>>>>>>>> a) >> >>>>>>>>>> >> >>>>>>>>>>> <!--[rfced] Section 5.2.3 vs. IANA Considerations: >> >>>>>>>>>>> Should this text be updated to match the IANA-registered >> >>>>>>>>>>> description >> >>>>>>>>>>> of each bit (which appears in Tables 6 and 7), or is it >> >>>>>>>>>>> intentional >> >>>>>>>>>>> for Section 5.2.3 to differ? >> >>>>>>>>>>> >> >>>>>>>>>>> - See >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> invalidatio__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdERpoSN$ [iana[.]org] >> >>>>>>>>>>> n-operational-flags >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> * D: dropping - the LSP is actively dropping traffic as a >> >>>>>>>>>>> result of >> >>>>>>>>>>> Drop-upon-invalid behavior being activated. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if it should match the IANA registry, including the >> >>>>>>>>>>> capitalization change which we will request): >> >>>>>>>>>>> >> >>>>>>>>>>> * D: Dropping - the LSP is currently attracting traffic and >> >>>>>>>>>>> actively dropping it. >> >>>>>>>>>>> >> >>>>>>>>>>> - See >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> invalidatio__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdERpoSN$ [iana[.]org] >> >>>>>>>>>>> n-configuration-flags >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> * D: drop enabled - the Candidate Path has Drop-upon-invalid >> >>>>>>>>>>> feature >> >>>>>>>>>>> enabled. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if it should match the IANA registry, including the >> >>>>>>>>>>> capitalization changes that we will request): >> >>>>>>>>>>> >> >>>>>>>>>>> * D: Drop enabled - the Drop-Upon-Invalid is enabled on the >> >>>>>>>>>>> LSP. >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> Text in section 5.2.3 was intentionally updated based on >> >>>>>>>>>>> comments, so it would be better to do not revert it back to >> >>>>>>>>>>> text from IANA section. Either we can keep in current way >> >>>>>>>>>>> (different text in Section 5.2.3 and IANA considerations) or >> >>>>>>>>>>> we will need to update IANA registry as well. >> >>>>>>>>>> >> >>>>>>>>>> We have left the text in Section 5.2.3 as is and have updated >> >>>>>>>>>> these definitions in the IANA Considerations section (Sections >> >>>>>>>>>> 6.5 and 6.6) to match how they appear in Section 5.2.3. Note >> >>>>>>>>>> that we will ask IANA to make this update along with the other >> >>>>>>>>>> registry updates. >> >>>>>>>>>> >> >>>>>>>>>> b) >> >>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Please review the following questions about >> >>>>>>>>>>> terminology. >> >>>>>>>>>>> >> >>>>>>>>>>> a) We note the following different uses of the term below. >> >>>>>>>>>>> Please >> >>>>>>>>>>> review and let us know how to update for consistency. >> >>>>>>>>>>> >> >>>>>>>>>>> EXPLICIT-NULL-LABEL-POLICY (as seen in Table 2) Explicit NULL >> >>>>>>>>>>> Label >> >>>>>>>>>>> Policy (ENLP) TLV Explicit Null Label Policy (ENLP) TLV >> >>>>>>>>>>> Explicit NULL >> >>>>>>>>>>> Label Policy (E-Flag) Explicit NULL Label [RFC3032] Explicit >> >>>>>>>>>>> Null >> >>>>>>>>>>> Label Policy Explicit NULL label/s explicit null label Note >> >>>>>>>>>>> that >> >>>>>>>>>>> Explicit Null is… >> >>>>>>>>>> >> >>>>>>>>>>> • Term Explicit NULL is used in RFC3032, so please use >> >>>>>>>>>>> “Explicit NULL Label Policy (ENLP) TLV” for TLV name and >> >>>>>>>>>>> “Explicit NULL Label Policy (E-Flag)” for Flag. >> >>>>>>>>>> >> >>>>>>>>>> We have updated the items above accordingly. Please note that >> >>>>>>>>>> we have also updated the terms below (all from Section 5.2.2.) >> >>>>>>>>>> as follows. Please review and let us know if these updates are >> >>>>>>>>>> suitable: >> >>>>>>>>>> >> >>>>>>>>>> OLD: >> >>>>>>>>>> >> >>>>>>>>>> Explicit NULL Label [RFC3032] >> >>>>>>>>>> Explicit NULL label >> >>>>>>>>>> Explicit Null is currently only defined for… explicit null >> >>>>>>>>>> label >> >>>>>>>>>> >> >>>>>>>>>> NEW: >> >>>>>>>>>> >> >>>>>>>>>> Explicit NULL label [RFC3032] >> >>>>>>>>>> Explicit NULL label >> >>>>>>>>>> Explicit NULL is currently only defined for… Explicit NULL >> >>>>>>>>>> label >> >>>>>>>>>> >> >>>>>>>>>> Upon careful review, please contact us with any further updates >> >>>>>>>>>> or with your approval of the document in its current form. We >> >>>>>>>>>> will await approvals from each author listed on the AUTH48 >> >>>>>>>>>> status page prior to moving forward in the publication process. >> >>>>>>>>>> >> >>>>>>>>>> The AUTH48 status page for this document is available here: >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/auth48/rfc9862__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLW4CdYiQ$ [rfc-editor[.]org] >> >>>>>>>>>> >> >>>>>>>>>> Please review the document carefully to ensure satisfaction as >> >>>>>>>>>> we do not make changes once it has been published as an RFC. >> >>>>>>>>>> >> >>>>>>>>>> — FILES (please refresh): — >> >>>>>>>>>> >> >>>>>>>>>> The updated files have been posted here: >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862.txt__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUD2iauT$ [rfc-editor[.]org] >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862.pdf__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLS4fEcvY$ [rfc-editor[.]org] >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLU3OXvQT$ [rfc-editor[.]org] >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862.xml__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUR6Qve7$ [rfc-editor[.]org] >> >>>>>>>>>> >> >>>>>>>>>> The relevant diff files have been posted here: >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>> auth48diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLa64r9iz$ [rfc-editor[.]org] >> >>>>>>>>>> (AUTH48 changes only) >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>> auth48rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLStiXoII$ [rfc-editor[.]org] >> >>>>>>>>>> (AUTH 48 changes side by side) >> >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>> diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWkkQJ2v$ [rfc-editor[.]org] >> >>>>>>>>>> (all changes) https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>> rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWA0wzhO$ [rfc-editor[.]org] >> >>>>>>>>>> (all changes side by side) >> >>>>>>>>>> >> >>>>>>>>>> Thank you for your time, >> >>>>>>>>>> >> >>>>>>>>>> Kaelin Foody >> >>>>>>>>>> RFC Production Center >> >>>>>>>>>> >> >>>>>>>>>>> On Sep 23, 2025, at 9:15 AM, Samuel Sidor (ssidor) >> >>>>>>>>>>> [email protected] wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Hi RFC editor, >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks a lot for your work! The diff looks fine to me. >> >>>>>>>>>>> >> >>>>>>>>>>> For inline comments from XML: >> >>>>>>>>>>> >> >>>>>>>>>>> • Global: >> >>>>>>>>>>> <!-- [rfced] This document updates RFC 8231. Please review the >> >>>>>>>>>>> errata >> >>>>>>>>>>> reported for RFC 8231 >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/errata/rfc8231__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLctT8ChH$ [rfc-editor[.]org] >> >>>>>>>>>>> and confirm that none are relevant to the content of this >> >>>>>>>>>>> document. —> >> >>>>>>>>>>> >> >>>>>>>>>>> RFC 8281 errata checked, but I don’t see any of them being >> >>>>>>>>>>> relevant to >> >>>>>>>>>>> this document >> >>>>>>>>>>> >> >>>>>>>>>>> • Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Please insert any keywords (beyond those that >> >>>>>>>>>>> appear in >> >>>>>>>>>>> the title) for use on >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/search__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLQZX0Xaa$ [rfc-editor[.]org]. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> OLD: >> >>>>>>>>>>> <keyword>example</keyword> >> >>>>>>>>>>> >> >>>>>>>>>>> NEW: >> >>>>>>>>>>> <keyword>PCEP</keyword> >> >>>>>>>>>>> <keyword>SR Policy</keyword> >> >>>>>>>>>>> <keyword>Candidate-Path</keyword> >> >>>>>>>>>>> >> >>>>>>>>>>> • Introduction >> >>>>>>>>>>> <!-- [rfced] FYI, we added "for" here to make the meaning of >> >>>>>>>>>>> the >> >>>>>>>>>>> parenthetical more clear. Please let us know if you prefer >> >>>>>>>>>>> otherwise. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Also, this document updates Section 5.8.2 of [RFC8231], making >> >>>>>>>>>>> the >> >>>>>>>>>>> use of Path Computation Request (PCReq) and Path Computation >> >>>>>>>>>>> Reply >> >>>>>>>>>>> (PCRep) messages optional for LSPs setup using Path Setup Type >> >>>>>>>>>>> 1 >> >>>>>>>>>>> (Segment Routing) [RFC8664] and Path Setup Type 3 (SRv6) >> >>>>>>>>>>> [RFC9603] >> >>>>>>>>>>> with the aim of reducing the PCEP message exchanges and >> >>>>>>>>>>> simplifying >> >>>>>>>>>>> implementation. >> >>>>>>>>>>> [...] >> >>>>>>>>>>> >> >>>>>>>>>>> SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 >> >>>>>>>>>>> (Segment Routing) or 3 (SRv6). >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> Also, this document updates Section 5.8.2 of [RFC8231], making >> >>>>>>>>>>> the >> >>>>>>>>>>> use of Path Computation Request (PCReq) and Path Computation >> >>>>>>>>>>> Reply >> >>>>>>>>>>> (PCRep) messages optional for LSPs that are set up using Path >> >>>>>>>>>>> Setup >> >>>>>>>>>>> Type 1 (for Segment Routing) [RFC8664] and Path Setup Type 3 >> >>>>>>>>>>> (for >> >>>>>>>>>>> SRv6) [RFC9603] with the aim of reducing the PCEP message >> >>>>>>>>>>> exchanges >> >>>>>>>>>>> and simplifying implementation. >> >>>>>>>>>>> [...] >> >>>>>>>>>>> >> >>>>>>>>>>> SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 >> >>>>>>>>>>> (for >> >>>>>>>>>>> Segment Routing) or 3 (for SRv6). >> >>>>>>>>>>> —> >> >>>>>>>>>>> I’m fine with updated text >> >>>>>>>>>>> >> >>>>>>>>>>> • Association Parameters >> >>>>>>>>>>> <!-- [rfced] We note that Figure 1 differs slightly from the >> >>>>>>>>>>> other TLV >> >>>>>>>>>>> format figures in this document. Specifically, Figure 1 >> >>>>>>>>>>> contains >> >>>>>>>>>>> values for Type and Length within the figure itself. Do you >> >>>>>>>>>>> want to >> >>>>>>>>>>> remove these values from Figure 1 for consistency with the >> >>>>>>>>>>> other figures in this document? >> >>>>>>>>>>> >> >>>>>>>>>>> Figure 1: >> >>>>>>>>>>> >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type = 31 | Length = 8 or 20 | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> Figure 2: >> >>>>>>>>>>> >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type | Length | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> FYI, we updated the first list item after Figure 1 for >> >>>>>>>>>>> consistency >> >>>>>>>>>>> with the other lists/figures. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Type: Extended Association ID TLV, type = 31 [RFC8697]. >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> Type: 31 for the Extended Association ID TLV [RFC8697]. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> Figure 1 can be aligned with other figures. >> >>>>>>>>>>> >> >>>>>>>>>>> OLD: >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type = 31 | Length = 8 or 20 | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> NEW: >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type | Length | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> Updated text after Figure 1 is fine. >> >>>>>>>>>>> >> >>>>>>>>>>> • Association Information >> >>>>>>>>>>> >> >>>>>>>>>>> <!--[rfced] FYI, several section titles have been updated to >> >>>>>>>>>>> exactly >> >>>>>>>>>>> match the TLV name. If you prefer the original section titles, >> >>>>>>>>>>> please >> >>>>>>>>>>> let us know. For example: >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> 4.5.1. SR Policy Name TLV >> >>>>>>>>>>> 4.5.2. SR Policy Candidate Path Identifier TLV >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> 4.5.1. SRPOLICY-POL-NAME TLV >> >>>>>>>>>>> 4.5.2. SRPOLICY-CPATH-ID TLV >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> It makes sense to have them aligned with actual TLV names, so >> >>>>>>>>>>> updated text is fine. >> >>>>>>>>>>> >> >>>>>>>>>>> • SR Policy Signaling Extensions >> >>>>>>>>>>> <!-- [rfced] For clarity, may we update this text as follows? >> >>>>>>>>>>> This includes adding "they" after "therefore", adding >> >>>>>>>>>>> punctuation, and >> >>>>>>>>>>> splitting the second sentence into two sentences. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> This section introduces mechanisms described for SR Policies >> >>>>>>>>>>> in >> >>>>>>>>>>> [RFC9256] to PCEP. These extensions do not make use of the >> >>>>>>>>>>> SRPA for >> >>>>>>>>>>> signaling in PCEP therefore cannot rely on the Association >> >>>>>>>>>>> capability >> >>>>>>>>>>> negotiation in ASSOC-Type-List TLV and separate capability >> >>>>>>>>>>> negotiation is required. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps: >> >>>>>>>>>>> This section introduces mechanisms described for SR Policies >> >>>>>>>>>>> in >> >>>>>>>>>>> [RFC9256] to PCEP. These extensions do not make use of the >> >>>>>>>>>>> SRPA for >> >>>>>>>>>>> signaling in PCEP; therefore, they cannot rely on the >> >>>>>>>>>>> Association >> >>>>>>>>>>> capability negotiation in the ASSOC-Type-List TLV. Instead, >> >>>>>>>>>>> separate >> >>>>>>>>>>> capability negotiation is required. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> I’m fine with updated text. >> >>>>>>>>>>> >> >>>>>>>>>>> 7. Invalidation TLV >> >>>>>>>>>>> >> >>>>>>>>>>> <!--[rfced] Section 5.2.3 vs. IANA Considerations: >> >>>>>>>>>>> Should this text be updated to match the IANA-registered >> >>>>>>>>>>> description >> >>>>>>>>>>> of each bit (which appears in Tables 6 and 7), or is it >> >>>>>>>>>>> intentional >> >>>>>>>>>>> for Section 5.2.3 to differ? >> >>>>>>>>>>> >> >>>>>>>>>>> - See >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> invalidatio__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdERpoSN$ [iana[.]org] >> >>>>>>>>>>> n-operational-flags >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> * D: dropping - the LSP is actively dropping traffic as a >> >>>>>>>>>>> result of >> >>>>>>>>>>> Drop-upon-invalid behavior being activated. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if it should match the IANA registry, including the >> >>>>>>>>>>> capitalization change which we will request): >> >>>>>>>>>>> >> >>>>>>>>>>> * D: Dropping - the LSP is currently attracting traffic and >> >>>>>>>>>>> actively dropping it. >> >>>>>>>>>>> >> >>>>>>>>>>> - See >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> invalidatio__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdERpoSN$ [iana[.]org] >> >>>>>>>>>>> n-configuration-flags >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> * D: drop enabled - the Candidate Path has Drop-upon-invalid >> >>>>>>>>>>> feature >> >>>>>>>>>>> enabled. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if it should match the IANA registry, including the >> >>>>>>>>>>> capitalization changes that we will request): >> >>>>>>>>>>> >> >>>>>>>>>>> * D: Drop enabled - the Drop-Upon-Invalid is enabled on the >> >>>>>>>>>>> LSP. >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> Text in section 5.2.3 was intentionally updated based on >> >>>>>>>>>>> comments, so it would be better to do not revert it back to >> >>>>>>>>>>> text from IANA section. Either we can keep in current way >> >>>>>>>>>>> (different text in Section 5.2.3 and IANA considerations) or >> >>>>>>>>>>> we will need to update IANA registry as well. >> >>>>>>>>>>> >> >>>>>>>>>>> 8. Drop-Upon-Invalid Applies to SR Policy >> >>>>>>>>>>> >> >>>>>>>>>>> <!--[rfced] Section 5.2.3.1: Does 'the D (dropping) flag set' >> >>>>>>>>>>> refer to >> >>>>>>>>>>> the D flag (Dropping) from Figure 10 or the D flag (Drop >> >>>>>>>>>>> enabled) from >> >>>>>>>>>>> Figure 11? >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Note that only one Candidate Path >> >>>>>>>>>>> needs to be reported to the PCE with the D (dropping) flag >> >>>>>>>>>>> set. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if from Figure 10): >> >>>>>>>>>>> Note that only one Candidate Path >> >>>>>>>>>>> needs to be reported to the PCE with the Dropping (D) flag >> >>>>>>>>>>> set. >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> Dropping flag is referring to “D flag (Dropping)”, so proposed >> >>>>>>>>>>> text is fine. >> >>>>>>>>>>> >> >>>>>>>>>>> 9. Information and Data Models >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Does "described in Section 4" refer to Section 4 >> >>>>>>>>>>> of this >> >>>>>>>>>>> document or Section 4 of [I-D.ietf-pce-pcep-srv6-yang]? >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> [I-D.ietf-pce-pcep-srv6-yang] defines YANG module with common >> >>>>>>>>>>> building blocks for PCEP Extensions described in Section 4. >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> This refers to section 4 of this/current document. >> >>>>>>>>>>> >> >>>>>>>>>>> 10. Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Please review the following questions about >> >>>>>>>>>>> terminology. >> >>>>>>>>>>> >> >>>>>>>>>>> a) We note the following different uses of the term below. >> >>>>>>>>>>> Please >> >>>>>>>>>>> review and let us know how to update for consistency. >> >>>>>>>>>>> >> >>>>>>>>>>> EXPLICIT-NULL-LABEL-POLICY (as seen in Table 2) Explicit NULL >> >>>>>>>>>>> Label >> >>>>>>>>>>> Policy (ENLP) TLV Explicit Null Label Policy (ENLP) TLV >> >>>>>>>>>>> Explicit NULL >> >>>>>>>>>>> Label Policy (E-Flag) Explicit NULL Label [RFC3032] Explicit >> >>>>>>>>>>> Null >> >>>>>>>>>>> Label Policy Explicit NULL label/s explicit null label Note >> >>>>>>>>>>> that >> >>>>>>>>>>> Explicit Null is... >> >>>>>>>>>>> >> >>>>>>>>>>> b) We note different capitalization for the terms below. >> >>>>>>>>>>> Please review >> >>>>>>>>>>> and let us know how to update for consistency. >> >>>>>>>>>>> >> >>>>>>>>>>> Destination vs. destination >> >>>>>>>>>>> >> >>>>>>>>>>> Preference vs. preference >> >>>>>>>>>>> >> >>>>>>>>>>> Candidate Path vs. candidate path >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> • Term Explicit NULL is used in RFC3032, so please use >> >>>>>>>>>>> “Explicit NULL Label Policy (ENLP) TLV” for TLV name and >> >>>>>>>>>>> “Explicit NULL Label Policy (E-Flag)” for Flag. >> >>>>>>>>>>> • >> >>>>>>>>>>> • "Destination vs. destination” - all four occurrences can be >> >>>>>>>>>>> used with lowercase >> >>>>>>>>>>> • “Preference vs. preference" - that inconsistency seems to be >> >>>>>>>>>>> coming from “https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/rfc/rfc9256.html*name-preference-of-a-candidate- >> >>>>>>>>>>> p__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLZ0frfoo$ [rfc-editor[.]org]”. >> >>>>>>>>>>> Please use “Preference” in all occurrences except one >> >>>>>>>>>>> occurrence in section 5.2.3.1 in this statement, where usage >> >>>>>>>>>>> of “Preference” does not make sense: >> >>>>>>>>>>> If so, the SR Policy enters the drop >> >>>>>>>>>>> state and "activates" the highest preference Candidate Path >> >>>>>>>>>>> which has >> >>>>>>>>>>> the Drop-upon-invalid enabled. >> >>>>>>>>>>> >> >>>>>>>>>>> • “Candidate Path vs. candidate path” - please use “Candidate >> >>>>>>>>>>> Path" >> >>>>>>>>>>> >> >>>>>>>>>>> 11. Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] FYI - We have already updated the following terms >> >>>>>>>>>>> for >> >>>>>>>>>>> consistency within the document and to match usage in other >> >>>>>>>>>>> RFCs. Please review: >> >>>>>>>>>>> >> >>>>>>>>>>> a) For the terms below, we have updated the form(s) on the >> >>>>>>>>>>> left to the >> >>>>>>>>>>> form on the right. >> >>>>>>>>>>> >> >>>>>>>>>>> association type / Association type -> Association Type (per >> >>>>>>>>>>> RFC 8697) >> >>>>>>>>>>> >> >>>>>>>>>>> Association Parameters -> association parameters (per RFC >> >>>>>>>>>>> 8697) >> >>>>>>>>>>> >> >>>>>>>>>>> ASSOCIATION Object -> ASSOCIATION object (per RFC 8697) >> >>>>>>>>>>> >> >>>>>>>>>>> Protocol Origin -> Protocol-Origin (per Section 2.3 of RFC >> >>>>>>>>>>> 9256) >> >>>>>>>>>>> >> >>>>>>>>>>> Drop-upon-invalid -> Drop-Upon-Invalid (per Section 8.2 of RFC >> >>>>>>>>>>> 9256) >> >>>>>>>>>>> >> >>>>>>>>>>> b) We note flags are stylized differently throughout (see some >> >>>>>>>>>>> examples below). For consistency, we have updated all of these >> >>>>>>>>>>> instances to P-flag, E-flag, etc. >> >>>>>>>>>>> >> >>>>>>>>>>> P-flag >> >>>>>>>>>>> P flag >> >>>>>>>>>>> E-Flag >> >>>>>>>>>>> E flag >> >>>>>>>>>>> I-Flag >> >>>>>>>>>>> I flag >> >>>>>>>>>>> L-Flag >> >>>>>>>>>>> L flag >> >>>>>>>>>>> "L-Flag" >> >>>>>>>>>>> O-flag >> >>>>>>>>>>> >> >>>>>>>>>>> So, we will ask IANA to update to lowercase 'f' consistently >> >>>>>>>>>>> in the >> >>>>>>>>>>> description in this registry >> >>>>>>>>>>> (https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> capability__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLahEVur-$ [iana[.]org] >> >>>>>>>>>>> -tlv-flag-field) unless you let us know otherwise. >> >>>>>>>>>>> Specifically, for >> >>>>>>>>>>> bits 27, 29, and 30: >> >>>>>>>>>>> OLD: L-Flag, I-Flag, E-Flag >> >>>>>>>>>>> NEW: L-flag, I-flag, E-flag >> >>>>>>>>>>> >> >>>>>>>>>>> c) FYI, "<headend, color, endpoint>" has been capitalized for >> >>>>>>>>>>> consistency with Section 2.1 of [RFC9256]. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Per Section 2.1 of [RFC9256], an SR Policy is identified >> >>>>>>>>>>> through the >> >>>>>>>>>>> <headend, color, endpoint> tuple. >> >>>>>>>>>>> >> >>>>>>>>>>> The last hop of a computed SR Policy Candidate Path MAY differ >> >>>>>>>>>>> from >> >>>>>>>>>>> the Endpoint contained in the <headend, color, endpoint> >> >>>>>>>>>>> tuple. >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> Per Section 2.1 of [RFC9256], an SR Policy is identified >> >>>>>>>>>>> through the >> >>>>>>>>>>> <Headend, Color, Endpoint> tuple. >> >>>>>>>>>>> >> >>>>>>>>>>> The last hop of a computed SR Policy Candidate Path MAY differ >> >>>>>>>>>>> from the >> >>>>>>>>>>> Endpoint contained in the <Headend, Color, Endpoint> tuple. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> All of those are find. Thanks a lot for updating all of those. >> >>>>>>>>>>> >> >>>>>>>>>>> 12. Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Please review the "Inclusive Language" portion of >> >>>>>>>>>>> the >> >>>>>>>>>>> online Style Guide >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/styleguide/part2/*inclusive_language__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdfYCfBo$ [rfc-editor[.]org] >> >>>>>>>>>>> and let us know if any changes are needed. Updates of this >> >>>>>>>>>>> nature >> >>>>>>>>>>> typically result in more precise language, which is helpful >> >>>>>>>>>>> for readers. >> >>>>>>>>>>> >> >>>>>>>>>>> For example, please consider whether "native" should be >> >>>>>>>>>>> updated in the text below: >> >>>>>>>>>>> >> >>>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>>> reaching the >> >>>>>>>>>>> Endpoint and have decapsulated traffic be forwarded the rest >> >>>>>>>>>>> of the >> >>>>>>>>>>> path to the Endpoint node using the native Interior Gateway >> >>>>>>>>>>> Protocol >> >>>>>>>>>>> (IGP) path(s). >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> OLD: >> >>>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>>> reaching the >> >>>>>>>>>>> Endpoint and have decapsulated traffic be forwarded the rest >> >>>>>>>>>>> of the >> >>>>>>>>>>> path to the Endpoint node using the native Interior Gateway >> >>>>>>>>>>> Protocol >> >>>>>>>>>>> (IGP) path(s). >> >>>>>>>>>>> >> >>>>>>>>>>> NEW: >> >>>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>>> reaching the >> >>>>>>>>>>> Endpoint and have decapsulated traffic be forwarded the rest >> >>>>>>>>>>> of the >> >>>>>>>>>>> path to the Endpoint node using the Interior Gateway Protocol >> >>>>>>>>>>> (IGP) shortest path(s). >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks a lot, >> >>>>>>>>>>> Samuel >> >>>>>>>>>>> >> >>>>>>>>>>> From: [email protected] [email protected] >> >>>>>>>>>>> Date: Friday, 19 September 2025 at 07:49 >> >>>>>>>>>>> To: [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected], Samuel Sidor (ssidor) [email protected], >> >>>>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected], >> >>>>>>>>>>> [email protected][email protected] >> >>>>>>>>>>> Cc: [email protected] [email protected], >> >>>>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected], [email protected] [email protected], >> >>>>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected] >> >>>>>>>>>>> Subject: AUTH48: RFC-to-be 9862 >> >>>>>>>>>>> <draft-ietf-pce-segment-routing-policy-cp-27> for your review >> >>>>>>>>>>> >> >>>>>>>>>>> IMPORTANT >> >>>>>>>>>>> >> >>>>>>>>>>> Updated 2025/09/18 >> >>>>>>>>>>> >> >>>>>>>>>>> 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://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/faq/__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLRaGma7i$ [rfc-editor[.]org]). >> >>>>>>>>>>> >> >>>>>>>>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license- >> >>>>>>>>>>> info__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLYFqGt7d$ >> >>>>>>>>>>> [trustee[.]ietf[.]org]). >> >>>>>>>>>>> >> >>>>>>>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml- >> >>>>>>>>>>> vocabulary__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLbWmC-CU$ >> >>>>>>>>>>> [authors[.]ietf[.]org]. >> >>>>>>>>>>> >> >>>>>>>>>>> * 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 >> >>>>>>>>>>> >> >>>>>>>>>>> * [email protected] (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). >> >>>>>>>>>>> >> >>>>>>>>>>> * [email protected], which is a new archival >> >>>>>>>>>>> mailing list >> >>>>>>>>>>> to preserve AUTH48 conversations; it is not an active >> >>>>>>>>>>> discussion >> >>>>>>>>>>> list: >> >>>>>>>>>>> >> >>>>>>>>>>> * More info: >> >>>>>>>>>>> >> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf- >> >>>>>>>>>>> announce/yb6lpIGh- >> >>>>>>>>>>> 4Q9l2USxI__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLRD-rv89$ >> >>>>>>>>>>> [mailarchive[.]ietf[.]org] >> >>>>>>>>>>> Ae6P8O4Zc >> >>>>>>>>>>> >> >>>>>>>>>>> * The archive itself: >> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLYyh_X6J$ >> >>>>>>>>>>> [mailarchive[.]ietf[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> * 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, >> >>>>>>>>>>> [email protected] 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://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.xml__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUR6Qve7$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLU3OXvQT$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.pdf__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLS4fEcvY$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.txt__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUD2iauT$ [rfc-editor[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> Diff file of the text: >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>>> diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWkkQJ2v$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>>> rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWA0wzhO$ [rfc-editor[.]org] >> >>>>>>>>>>> (side by >> >>>>>>>>>>> side) >> >>>>>>>>>>> >> >>>>>>>>>>> Diff of the XML: >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>>> xmldiff1.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLfWVf5Dv$ [rfc-editor[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> Tracking progress >> >>>>>>>>>>> ----------------- >> >>>>>>>>>>> >> >>>>>>>>>>> The details of the AUTH48 status of your document are here: >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/auth48/rfc9862__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLW4CdYiQ$ [rfc-editor[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> Please let us know if you have any questions. >> >>>>>>>>>>> >> >>>>>>>>>>> Thank you for your cooperation, >> >>>>>>>>>>> >> >>>>>>>>>>> RFC Editor >> >>>>>>>>>>> >> >>>>>>>>>>> -------------------------------------- >> >>>>>>>>>>> RFC9862 (draft-ietf-pce-segment-routing-policy-cp-27) >> >>>>>>>>>>> >> >>>>>>>>>>> Title : Path Computation Element Communication Protocol (PCEP) >> >>>>>>>>>>> Extensions for Segment Routing (SR) Policy Candidate Paths >> >>>>>>>>>>> Author(s) : M. Koldychev, S. Sivabalan, S. Sidor, C. Barth, S. >> >>>>>>>>>>> Peng, H. Bidgoli >> >>>>>>>>>>> WG Chair(s) : Julien Meuric, Dhruv Dhody >> >>>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van >> >>>>>>>>>>> de Velde >> >>>>>>>>>> >> >>>>>>>>>>> On Sep 23, 2025, at 9:15 AM, Samuel Sidor (ssidor) >> >>>>>>>>>>> [email protected] wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Hi RFC editor, >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks a lot for your work! The diff looks fine to me. >> >>>>>>>>>>> >> >>>>>>>>>>> For inline comments from XML: >> >>>>>>>>>>> >> >>>>>>>>>>> • Global: >> >>>>>>>>>>> <!-- [rfced] This document updates RFC 8231. Please review the >> >>>>>>>>>>> errata >> >>>>>>>>>>> reported for RFC 8231 >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/errata/rfc8231__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLctT8ChH$ [rfc-editor[.]org] >> >>>>>>>>>>> and confirm that none are relevant to the content of this >> >>>>>>>>>>> document. —> >> >>>>>>>>>>> >> >>>>>>>>>>> RFC 8281 errata checked, but I don’t see any of them being >> >>>>>>>>>>> relevant to >> >>>>>>>>>>> this document >> >>>>>>>>>>> >> >>>>>>>>>>> • Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Please insert any keywords (beyond those that >> >>>>>>>>>>> appear in >> >>>>>>>>>>> the title) for use on >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/search__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLQZX0Xaa$ [rfc-editor[.]org]. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> OLD: >> >>>>>>>>>>> <keyword>example</keyword> >> >>>>>>>>>>> >> >>>>>>>>>>> NEW: >> >>>>>>>>>>> <keyword>PCEP</keyword> >> >>>>>>>>>>> <keyword>SR Policy</keyword> >> >>>>>>>>>>> <keyword>Candidate-Path</keyword> >> >>>>>>>>>>> >> >>>>>>>>>>> • Introduction >> >>>>>>>>>>> <!-- [rfced] FYI, we added "for" here to make the meaning of >> >>>>>>>>>>> the >> >>>>>>>>>>> parenthetical more clear. Please let us know if you prefer >> >>>>>>>>>>> otherwise. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Also, this document updates Section 5.8.2 of [RFC8231], making >> >>>>>>>>>>> the >> >>>>>>>>>>> use of Path Computation Request (PCReq) and Path Computation >> >>>>>>>>>>> Reply >> >>>>>>>>>>> (PCRep) messages optional for LSPs setup using Path Setup Type >> >>>>>>>>>>> 1 >> >>>>>>>>>>> (Segment Routing) [RFC8664] and Path Setup Type 3 (SRv6) >> >>>>>>>>>>> [RFC9603] >> >>>>>>>>>>> with the aim of reducing the PCEP message exchanges and >> >>>>>>>>>>> simplifying >> >>>>>>>>>>> implementation. >> >>>>>>>>>>> [...] >> >>>>>>>>>>> >> >>>>>>>>>>> SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 >> >>>>>>>>>>> (Segment Routing) or 3 (SRv6). >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> Also, this document updates Section 5.8.2 of [RFC8231], making >> >>>>>>>>>>> the >> >>>>>>>>>>> use of Path Computation Request (PCReq) and Path Computation >> >>>>>>>>>>> Reply >> >>>>>>>>>>> (PCRep) messages optional for LSPs that are set up using Path >> >>>>>>>>>>> Setup >> >>>>>>>>>>> Type 1 (for Segment Routing) [RFC8664] and Path Setup Type 3 >> >>>>>>>>>>> (for >> >>>>>>>>>>> SRv6) [RFC9603] with the aim of reducing the PCEP message >> >>>>>>>>>>> exchanges >> >>>>>>>>>>> and simplifying implementation. >> >>>>>>>>>>> [...] >> >>>>>>>>>>> >> >>>>>>>>>>> SR Policy LSP: An LSP setup using Path Setup Type [RFC8408] 1 >> >>>>>>>>>>> (for >> >>>>>>>>>>> Segment Routing) or 3 (for SRv6). >> >>>>>>>>>>> —> >> >>>>>>>>>>> I’m fine with updated text >> >>>>>>>>>>> >> >>>>>>>>>>> • Association Parameters >> >>>>>>>>>>> <!-- [rfced] We note that Figure 1 differs slightly from the >> >>>>>>>>>>> other TLV >> >>>>>>>>>>> format figures in this document. Specifically, Figure 1 >> >>>>>>>>>>> contains >> >>>>>>>>>>> values for Type and Length within the figure itself. Do you >> >>>>>>>>>>> want to >> >>>>>>>>>>> remove these values from Figure 1 for consistency with the >> >>>>>>>>>>> other figures in this document? >> >>>>>>>>>>> >> >>>>>>>>>>> Figure 1: >> >>>>>>>>>>> >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type = 31 | Length = 8 or 20 | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> Figure 2: >> >>>>>>>>>>> >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type | Length | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> FYI, we updated the first list item after Figure 1 for >> >>>>>>>>>>> consistency >> >>>>>>>>>>> with the other lists/figures. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Type: Extended Association ID TLV, type = 31 [RFC8697]. >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> Type: 31 for the Extended Association ID TLV [RFC8697]. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> Figure 1 can be aligned with other figures. >> >>>>>>>>>>> >> >>>>>>>>>>> OLD: >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type = 31 | Length = 8 or 20 | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> NEW: >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> | Type | Length | >> >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>>>>>>> +-+ >> >>>>>>>>>>> >> >>>>>>>>>>> Updated text after Figure 1 is fine. >> >>>>>>>>>>> >> >>>>>>>>>>> • Association Information >> >>>>>>>>>>> >> >>>>>>>>>>> <!--[rfced] FYI, several section titles have been updated to >> >>>>>>>>>>> exactly >> >>>>>>>>>>> match the TLV name. If you prefer the original section titles, >> >>>>>>>>>>> please >> >>>>>>>>>>> let us know. For example: >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> 4.5.1. SR Policy Name TLV >> >>>>>>>>>>> 4.5.2. SR Policy Candidate Path Identifier TLV >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> 4.5.1. SRPOLICY-POL-NAME TLV >> >>>>>>>>>>> 4.5.2. SRPOLICY-CPATH-ID TLV >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> It makes sense to have them aligned with actual TLV names, so >> >>>>>>>>>>> updated text is fine. >> >>>>>>>>>>> >> >>>>>>>>>>> • SR Policy Signaling Extensions >> >>>>>>>>>>> <!-- [rfced] For clarity, may we update this text as follows? >> >>>>>>>>>>> This includes adding "they" after "therefore", adding >> >>>>>>>>>>> punctuation, and >> >>>>>>>>>>> splitting the second sentence into two sentences. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> This section introduces mechanisms described for SR Policies >> >>>>>>>>>>> in >> >>>>>>>>>>> [RFC9256] to PCEP. These extensions do not make use of the >> >>>>>>>>>>> SRPA for >> >>>>>>>>>>> signaling in PCEP therefore cannot rely on the Association >> >>>>>>>>>>> capability >> >>>>>>>>>>> negotiation in ASSOC-Type-List TLV and separate capability >> >>>>>>>>>>> negotiation is required. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps: >> >>>>>>>>>>> This section introduces mechanisms described for SR Policies >> >>>>>>>>>>> in >> >>>>>>>>>>> [RFC9256] to PCEP. These extensions do not make use of the >> >>>>>>>>>>> SRPA for >> >>>>>>>>>>> signaling in PCEP; therefore, they cannot rely on the >> >>>>>>>>>>> Association >> >>>>>>>>>>> capability negotiation in the ASSOC-Type-List TLV. Instead, >> >>>>>>>>>>> separate >> >>>>>>>>>>> capability negotiation is required. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> I’m fine with updated text. >> >>>>>>>>>>> >> >>>>>>>>>>> 7. Invalidation TLV >> >>>>>>>>>>> >> >>>>>>>>>>> <!--[rfced] Section 5.2.3 vs. IANA Considerations: >> >>>>>>>>>>> Should this text be updated to match the IANA-registered >> >>>>>>>>>>> description >> >>>>>>>>>>> of each bit (which appears in Tables 6 and 7), or is it >> >>>>>>>>>>> intentional >> >>>>>>>>>>> for Section 5.2.3 to differ? >> >>>>>>>>>>> >> >>>>>>>>>>> - See >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> invalidatio__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdERpoSN$ [iana[.]org] >> >>>>>>>>>>> n-operational-flags >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> * D: dropping - the LSP is actively dropping traffic as a >> >>>>>>>>>>> result of >> >>>>>>>>>>> Drop-upon-invalid behavior being activated. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if it should match the IANA registry, including the >> >>>>>>>>>>> capitalization change which we will request): >> >>>>>>>>>>> >> >>>>>>>>>>> * D: Dropping - the LSP is currently attracting traffic and >> >>>>>>>>>>> actively dropping it. >> >>>>>>>>>>> >> >>>>>>>>>>> - See >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> invalidatio__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdERpoSN$ [iana[.]org] >> >>>>>>>>>>> n-configuration-flags >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> * D: drop enabled - the Candidate Path has Drop-upon-invalid >> >>>>>>>>>>> feature >> >>>>>>>>>>> enabled. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if it should match the IANA registry, including the >> >>>>>>>>>>> capitalization changes that we will request): >> >>>>>>>>>>> >> >>>>>>>>>>> * D: Drop enabled - the Drop-Upon-Invalid is enabled on the >> >>>>>>>>>>> LSP. >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> Text in section 5.2.3 was intentionally updated based on >> >>>>>>>>>>> comments, so it would be better to do not revert it back to >> >>>>>>>>>>> text from IANA section. Either we can keep in current way >> >>>>>>>>>>> (different text in Section 5.2.3 and IANA considerations) or >> >>>>>>>>>>> we will need to update IANA registry as well. >> >>>>>>>>>>> >> >>>>>>>>>>> 8. Drop-Upon-Invalid Applies to SR Policy >> >>>>>>>>>>> >> >>>>>>>>>>> <!--[rfced] Section 5.2.3.1: Does 'the D (dropping) flag set' >> >>>>>>>>>>> refer to >> >>>>>>>>>>> the D flag (Dropping) from Figure 10 or the D flag (Drop >> >>>>>>>>>>> enabled) from >> >>>>>>>>>>> Figure 11? >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Note that only one Candidate Path >> >>>>>>>>>>> needs to be reported to the PCE with the D (dropping) flag >> >>>>>>>>>>> set. >> >>>>>>>>>>> >> >>>>>>>>>>> Perhaps (if from Figure 10): >> >>>>>>>>>>> Note that only one Candidate Path >> >>>>>>>>>>> needs to be reported to the PCE with the Dropping (D) flag >> >>>>>>>>>>> set. >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> Dropping flag is referring to “D flag (Dropping)”, so proposed >> >>>>>>>>>>> text is fine. >> >>>>>>>>>>> >> >>>>>>>>>>> 9. Information and Data Models >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Does "described in Section 4" refer to Section 4 >> >>>>>>>>>>> of this >> >>>>>>>>>>> document or Section 4 of [I-D.ietf-pce-pcep-srv6-yang]? >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> [I-D.ietf-pce-pcep-srv6-yang] defines YANG module with common >> >>>>>>>>>>> building blocks for PCEP Extensions described in Section 4. >> >>>>>>>>>>> --> >> >>>>>>>>>>> >> >>>>>>>>>>> This refers to section 4 of this/current document. >> >>>>>>>>>>> >> >>>>>>>>>>> 10. Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Please review the following questions about >> >>>>>>>>>>> terminology. >> >>>>>>>>>>> >> >>>>>>>>>>> a) We note the following different uses of the term below. >> >>>>>>>>>>> Please >> >>>>>>>>>>> review and let us know how to update for consistency. >> >>>>>>>>>>> >> >>>>>>>>>>> EXPLICIT-NULL-LABEL-POLICY (as seen in Table 2) Explicit NULL >> >>>>>>>>>>> Label >> >>>>>>>>>>> Policy (ENLP) TLV Explicit Null Label Policy (ENLP) TLV >> >>>>>>>>>>> Explicit NULL >> >>>>>>>>>>> Label Policy (E-Flag) Explicit NULL Label [RFC3032] Explicit >> >>>>>>>>>>> Null >> >>>>>>>>>>> Label Policy Explicit NULL label/s explicit null label Note >> >>>>>>>>>>> that >> >>>>>>>>>>> Explicit Null is... >> >>>>>>>>>>> >> >>>>>>>>>>> b) We note different capitalization for the terms below. >> >>>>>>>>>>> Please review >> >>>>>>>>>>> and let us know how to update for consistency. >> >>>>>>>>>>> >> >>>>>>>>>>> Destination vs. destination >> >>>>>>>>>>> >> >>>>>>>>>>> Preference vs. preference >> >>>>>>>>>>> >> >>>>>>>>>>> Candidate Path vs. candidate path >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> • Term Explicit NULL is used in RFC3032, so please use >> >>>>>>>>>>> “Explicit NULL Label Policy (ENLP) TLV” for TLV name and >> >>>>>>>>>>> “Explicit NULL Label Policy (E-Flag)” for Flag. >> >>>>>>>>>>> • >> >>>>>>>>>>> • "Destination vs. destination” - all four occurrences can be >> >>>>>>>>>>> used with lowercase >> >>>>>>>>>>> • “Preference vs. preference" - that inconsistency seems to be >> >>>>>>>>>>> coming from “https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/rfc/rfc9256.html*name-preference-of-a-candidate- >> >>>>>>>>>>> p__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLZ0frfoo$ [rfc-editor[.]org]”. >> >>>>>>>>>>> Please use “Preference” in all occurrences except one >> >>>>>>>>>>> occurrence in section 5.2.3.1 in this statement, where usage >> >>>>>>>>>>> of “Preference” does not make sense: >> >>>>>>>>>>> If so, the SR Policy enters the drop >> >>>>>>>>>>> state and "activates" the highest preference Candidate Path >> >>>>>>>>>>> which has >> >>>>>>>>>>> the Drop-upon-invalid enabled. >> >>>>>>>>>>> >> >>>>>>>>>>> • “Candidate Path vs. candidate path” - please use “Candidate >> >>>>>>>>>>> Path" >> >>>>>>>>>>> >> >>>>>>>>>>> 11. Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] FYI - We have already updated the following terms >> >>>>>>>>>>> for >> >>>>>>>>>>> consistency within the document and to match usage in other >> >>>>>>>>>>> RFCs. Please review: >> >>>>>>>>>>> >> >>>>>>>>>>> a) For the terms below, we have updated the form(s) on the >> >>>>>>>>>>> left to the >> >>>>>>>>>>> form on the right. >> >>>>>>>>>>> >> >>>>>>>>>>> association type / Association type -> Association Type (per >> >>>>>>>>>>> RFC 8697) >> >>>>>>>>>>> >> >>>>>>>>>>> Association Parameters -> association parameters (per RFC >> >>>>>>>>>>> 8697) >> >>>>>>>>>>> >> >>>>>>>>>>> ASSOCIATION Object -> ASSOCIATION object (per RFC 8697) >> >>>>>>>>>>> >> >>>>>>>>>>> Protocol Origin -> Protocol-Origin (per Section 2.3 of RFC >> >>>>>>>>>>> 9256) >> >>>>>>>>>>> >> >>>>>>>>>>> Drop-upon-invalid -> Drop-Upon-Invalid (per Section 8.2 of RFC >> >>>>>>>>>>> 9256) >> >>>>>>>>>>> >> >>>>>>>>>>> b) We note flags are stylized differently throughout (see some >> >>>>>>>>>>> examples below). For consistency, we have updated all of these >> >>>>>>>>>>> instances to P-flag, E-flag, etc. >> >>>>>>>>>>> >> >>>>>>>>>>> P-flag >> >>>>>>>>>>> P flag >> >>>>>>>>>>> E-Flag >> >>>>>>>>>>> E flag >> >>>>>>>>>>> I-Flag >> >>>>>>>>>>> I flag >> >>>>>>>>>>> L-Flag >> >>>>>>>>>>> L flag >> >>>>>>>>>>> "L-Flag" >> >>>>>>>>>>> O-flag >> >>>>>>>>>>> >> >>>>>>>>>>> So, we will ask IANA to update to lowercase 'f' consistently >> >>>>>>>>>>> in the >> >>>>>>>>>>> description in this registry >> >>>>>>>>>>> (https://urldefense.com/v3/__https://www.iana.org/assignments/pcep/pcep.xhtml*sr- >> >>>>>>>>>>> policy- >> >>>>>>>>>>> capability__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLahEVur-$ [iana[.]org] >> >>>>>>>>>>> -tlv-flag-field) unless you let us know otherwise. >> >>>>>>>>>>> Specifically, for >> >>>>>>>>>>> bits 27, 29, and 30: >> >>>>>>>>>>> OLD: L-Flag, I-Flag, E-Flag >> >>>>>>>>>>> NEW: L-flag, I-flag, E-flag >> >>>>>>>>>>> >> >>>>>>>>>>> c) FYI, "<headend, color, endpoint>" has been capitalized for >> >>>>>>>>>>> consistency with Section 2.1 of [RFC9256]. >> >>>>>>>>>>> >> >>>>>>>>>>> Original: >> >>>>>>>>>>> Per Section 2.1 of [RFC9256], an SR Policy is identified >> >>>>>>>>>>> through the >> >>>>>>>>>>> <headend, color, endpoint> tuple. >> >>>>>>>>>>> >> >>>>>>>>>>> The last hop of a computed SR Policy Candidate Path MAY differ >> >>>>>>>>>>> from >> >>>>>>>>>>> the Endpoint contained in the <headend, color, endpoint> >> >>>>>>>>>>> tuple. >> >>>>>>>>>>> >> >>>>>>>>>>> Current: >> >>>>>>>>>>> Per Section 2.1 of [RFC9256], an SR Policy is identified >> >>>>>>>>>>> through the >> >>>>>>>>>>> <Headend, Color, Endpoint> tuple. >> >>>>>>>>>>> >> >>>>>>>>>>> The last hop of a computed SR Policy Candidate Path MAY differ >> >>>>>>>>>>> from the >> >>>>>>>>>>> Endpoint contained in the <Headend, Color, Endpoint> tuple. >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> All of those are find. Thanks a lot for updating all of those. >> >>>>>>>>>>> >> >>>>>>>>>>> 12. Global >> >>>>>>>>>>> >> >>>>>>>>>>> <!-- [rfced] Please review the "Inclusive Language" portion of >> >>>>>>>>>>> the >> >>>>>>>>>>> online Style Guide >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/styleguide/part2/*inclusive_language__;Iw!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLdfYCfBo$ [rfc-editor[.]org] >> >>>>>>>>>>> and let us know if any changes are needed. Updates of this >> >>>>>>>>>>> nature >> >>>>>>>>>>> typically result in more precise language, which is helpful >> >>>>>>>>>>> for readers. >> >>>>>>>>>>> >> >>>>>>>>>>> For example, please consider whether "native" should be >> >>>>>>>>>>> updated in the text below: >> >>>>>>>>>>> >> >>>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>>> reaching the >> >>>>>>>>>>> Endpoint and have decapsulated traffic be forwarded the rest >> >>>>>>>>>>> of the >> >>>>>>>>>>> path to the Endpoint node using the native Interior Gateway >> >>>>>>>>>>> Protocol >> >>>>>>>>>>> (IGP) path(s). >> >>>>>>>>>>> —> >> >>>>>>>>>>> >> >>>>>>>>>>> OLD: >> >>>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>>> reaching the >> >>>>>>>>>>> Endpoint and have decapsulated traffic be forwarded the rest >> >>>>>>>>>>> of the >> >>>>>>>>>>> path to the Endpoint node using the native Interior Gateway >> >>>>>>>>>>> Protocol >> >>>>>>>>>>> (IGP) path(s). >> >>>>>>>>>>> >> >>>>>>>>>>> NEW: >> >>>>>>>>>>> An example use case is to terminate the SR Policy before >> >>>>>>>>>>> reaching the >> >>>>>>>>>>> Endpoint and have decapsulated traffic be forwarded the rest >> >>>>>>>>>>> of the >> >>>>>>>>>>> path to the Endpoint node using the Interior Gateway Protocol >> >>>>>>>>>>> (IGP) shortest path(s). >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks a lot, >> >>>>>>>>>>> Samuel >> >>>>>>>>>>> >> >>>>>>>>>>> From: [email protected] [email protected] >> >>>>>>>>>>> Date: Friday, 19 September 2025 at 07:49 >> >>>>>>>>>>> To: [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected], Samuel Sidor (ssidor) [email protected], >> >>>>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected], [email protected] >> >>>>>>>>>>> [email protected] >> >>>>>>>>>>> Cc: [email protected] [email protected], >> >>>>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected], [email protected] [email protected], >> >>>>>>>>>>> [email protected] [email protected], [email protected] >> >>>>>>>>>>> [email protected] >> >>>>>>>>>>> Subject: AUTH48: RFC-to-be 9862 >> >>>>>>>>>>> <draft-ietf-pce-segment-routing-policy-cp-27> for your review >> >>>>>>>>>>> >> >>>>>>>>>>> IMPORTANT >> >>>>>>>>>>> >> >>>>>>>>>>> Updated 2025/09/18 >> >>>>>>>>>>> >> >>>>>>>>>>> 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://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/faq/__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLRaGma7i$ [rfc-editor[.]org]). >> >>>>>>>>>>> >> >>>>>>>>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license- >> >>>>>>>>>>> info__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLYFqGt7d$ >> >>>>>>>>>>> [trustee[.]ietf[.]org]). >> >>>>>>>>>>> >> >>>>>>>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml- >> >>>>>>>>>>> vocabulary__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLbWmC-CU$ >> >>>>>>>>>>> [authors[.]ietf[.]org]. >> >>>>>>>>>>> >> >>>>>>>>>>> * 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 >> >>>>>>>>>>> >> >>>>>>>>>>> * [email protected] (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). >> >>>>>>>>>>> >> >>>>>>>>>>> * [email protected], which is a new archival >> >>>>>>>>>>> mailing list >> >>>>>>>>>>> to preserve AUTH48 conversations; it is not an active >> >>>>>>>>>>> discussion >> >>>>>>>>>>> list: >> >>>>>>>>>>> >> >>>>>>>>>>> * More info: >> >>>>>>>>>>> >> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf- >> >>>>>>>>>>> announce/yb6lpIGh- >> >>>>>>>>>>> 4Q9l2USxI__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLRD-rv89$ >> >>>>>>>>>>> [mailarchive[.]ietf[.]org] >> >>>>>>>>>>> Ae6P8O4Zc >> >>>>>>>>>>> >> >>>>>>>>>>> * The archive itself: >> >>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLYyh_X6J$ >> >>>>>>>>>>> [mailarchive[.]ietf[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> * 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, >> >>>>>>>>>>> [email protected] 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://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.xml__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUR6Qve7$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLU3OXvQT$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.pdf__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLS4fEcvY$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862.txt__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLUD2iauT$ [rfc-editor[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> Diff file of the text: >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>>> diff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWkkQJ2v$ [rfc-editor[.]org] >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>>> rfcdiff.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLWA0wzhO$ [rfc-editor[.]org] >> >>>>>>>>>>> (side by >> >>>>>>>>>>> side) >> >>>>>>>>>>> >> >>>>>>>>>>> Diff of the XML: >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/authors/rfc9862- >> >>>>>>>>>>> xmldiff1.html__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLfWVf5Dv$ [rfc-editor[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> Tracking progress >> >>>>>>>>>>> ----------------- >> >>>>>>>>>>> >> >>>>>>>>>>> The details of the AUTH48 status of your document are here: >> >>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >> >>>>>>>>>>> editor.org/auth48/rfc9862__;!!OSsGDw!NlhESSVXrTKw5qvdb1_8kSDDztDW2OQGBvNehPQ- >> >>>>>>>>>>> BQiIg069gAuTF_eNSPgoGak-OYgHZC0SLW4CdYiQ$ [rfc-editor[.]org] >> >>>>>>>>>>> >> >>>>>>>>>>> Please let us know if you have any questions. >> >>>>>>>>>>> >> >>>>>>>>>>> Thank you for your cooperation, >> >>>>>>>>>>> >> >>>>>>>>>>> RFC Editor >> >>>>>>>>>>> >> >>>>>>>>>>> -------------------------------------- >> >>>>>>>>>>> RFC9862 (draft-ietf-pce-segment-routing-policy-cp-27) >> >>>>>>>>>>> >> >>>>>>>>>>> Title : Path Computation Element Communication Protocol (PCEP) >> >>>>>>>>>>> Extensions for Segment Routing (SR) Policy Candidate Paths >> >>>>>>>>>>> Author(s) : M. Koldychev, S. Sivabalan, S. Sidor, C. Barth, S. >> >>>>>>>>>>> Peng, H. Bidgoli >> >>>>>>>>>>> WG Chair(s) : Julien Meuric, Dhruv Dhody >> >>>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van >> >>>>>>>>>>> de Velde >> >>>> >> >> >> > >> > >> > >> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
