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]
