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]; > [email protected] > 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] <[email protected]>, Colby Barth >> <[email protected]>, [email protected] <[email protected]>, >> [email protected] <[email protected]>, Dhruv Dhody <[email protected]>, >> [email protected] <[email protected]>, [email protected] >> <[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]; >> [email protected] >> 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]; >> [email protected] >> 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] 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] >>>>> [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 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] >>>>>> [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], [email protected] [email protected], >>>>>>> [email protected] [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]; [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]
