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]
