Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
draft-ietf-pce-segment-routing-policy-cp-27

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-pce-segment-routing-policy-cp and RFC 9862, changed IESG state to RFC Published)

[Ballot comment]
Thanks for addressing my discuss points/comments and other comments. Following are further comments suggested to improve the updated text that was introduced.

Provided inline in the idnits format output for the v26 of the document.

209   The term "LSP" in this document represents Candidate Path within an
210   SR Policy.  In the context of SR Policy for SRv6, the term "LSP" in
211   this document refers to an SRv6 path, which is represented as a list
212   of SRv6 segments.

How about?

CURRENT
In the context of SR Policy for SRv6, the term "LSP" in this document refers to
an SRv6 path, which is represented as a list of SRv6 segments.

SUGGEST
In the context of SR Policy for SRv6 (refer [RFC9603]), the term "LSP" in this
document refers to an SRv6 path, which is represented as a list of SRv6 segments.


249   [RFC8697] specifies the mechanism for the capability advertisement of
250   the Association Types supported by a PCEP speaker by defining an
251   ASSOC-Type-List TLV to be carried within an OPEN object.  This
252   capability exchange for the SR Policy Association Type MUST be done
253   before using the SRPA.  To that aim, a PCEP speaker MUST include the
254   SRPA Type (6) in the ASSOC-Type-List TLV and MUST receive the same
255   from the PCEP peer before using the SRPA (Section 6.1).  SRPA MUST be
256   assigned for all SR Policy LSPs by PCEP speaker originating the LSP
257   if capability was advertised by both PCEP speakers.

What would be the error reported by the PCEP speaker if it were to
received an SR LSP (say using mechanism in RFC8664) without an SRPA even after
successful capability negotiation? Perhaps there is an existing error that can
be used?

294   SR Policy Candidate Path Identifier uniquely identifies the SR Policy
295   Candidate Path within the context of an SR Policy.  SR Policy
296   Candidate Path Identifier is assigned by PCEP peer originating the
297   LSP.  Candidate Paths within an SR Policy MUST NOT change their SR
298   Policy Candidate Path Identifiers for the lifetime of the PCEP
299   session.  Candidate Paths within an SR Policy MUST NOT carry same SR
300   Policy Candidate Path Identifiers in their SRPAs.  If the above

How about?

CURRENT
Candidate Paths within an SR Policy MUST NOT carry same SR Policy Candidate Path Identifiers in their SRPAs.

SUGGEST
Two or more Candidate Paths within an SR Policy MUST NOT carry same SR Policy Candidate Path Identifiers in their SRPAs.


< EoR v26 >

[Ballot comment]
Thanks for *partially* addressing my blocking DISCUSS (including the last one, which was caused by my misreading of the I-D). I am clearing my DISCUSS.

***BUT***, I still find the text in section 3 very unclear about its applicability to SRv6, the LSP explanation added at the end of section 2 is enough to clear my previous DISCUSS, but ***the whole section can only confuse the readers***.

# Below kept for archiving

No need to act on anything below.

## Archive of DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 3

This section appears to be only about SR-MPLS, i.e., conflicting with the abstract, which explicitly includes SRv6, and the title, which does not mention any restriction to SR-MPLS only. Either add some SRv6 text (my preference) or restrict the I-D to SR-MPLS only.

### Section 4.1

Let's remove any ambiguity and specify the units (octets I guess) and the field coverage (color + endpoint I guess) for the Length field.

### Sections 4.2.1 & 4.2.3

`It is RECOMMENDED that the size of the symbolic name for the SR Policy is limited to 255 bytes. ` why only "RECOMMENDED" when the Length field can only indicate 255 maximum ? Suggest using MUST rather RECOMMENDED here.

*My bad on this one, Med corrected me*

## Archive of COMMENTS (non-blocking)

### Are RFC 8986 policies included ?

This document does not seem to include RFC 8986 (network programming) policies as it only talks about "paths". The document should be clear whether it supports RFC 8986 and, if so, amend the text about "paths".

### Abstract

Suggest deleting `called a headend node` as it brings no value there.

### Section 1

s/Path Setup Type 1 (Segment Routing) /Path Setup Type 1 (SR-MPLS) / ? (and possibly other places, let's remove any ambiguity)

### Sections 4.2.1 and 4.2.3

`Padding is not included in the Length field.` do PCEP receivers know how to handle a Length that does not really represent the length of the TLV ?

### Section 11.2

RFC20 should be normative.

## NITS (non-blocking / cosmetic)

### Section 1

Consider using lower case for `Establishing Relationships Between Sets`

### Section 5.1

Please use balanced quotes in `Type: 71 for "SRPOLICY-CAPABILITY TLV`

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-policy-cp-25
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Dhruv Dhody for the shepherd's write-up including the WG consensus, some justification for 6 authors, and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 3

This section appears to be only about SR-MPLS, i.e., conflicting with the abstract, which explicitly includes SRv6, and the title, which does not mention any restriction to SR-MPLS only. Either add some SRv6 text (my preference) or restrict the I-D to SR-MPLS only.

### Section 4.1

Let's remove any ambiguity and specify the units (octets I guess) and the field coverage (color + endpoint I guess) for the Length field.

### Sections 4.2.1 & 4.2.3

`It is RECOMMENDED that the size of the symbolic name for the SR Policy is limited to 255 bytes. ` why only "RECOMMENDED" when the Length field can only indicate 255 maximum ? Suggest using MUST rather RECOMMENDED here.

[Ballot comment]

## COMMENTS (non-blocking)

### Are RFC 8986 policies included ?

This document does not seem to include RFC 8986 (network programming) policies as it only talks about "paths". The document should be clear whether it supports RFC 8986 and, if so, amend the text about "paths".

### Abstract

Suggest deleting `called a headend node` as it brings no value there.

### Section 1

s/Path Setup Type 1 (Segment Routing) /Path Setup Type 1 (SR-MPLS) / ? (and possibly other places, let's remove any ambiguity)

### Sections 4.2.1 and 4.2.3

`Padding is not included in the Length field.` do PCEP receivers know how to handle a Length that does not really represent the length of the TLV ?

### Section 11.2

RFC20 should be normative.

## NITS (non-blocking / cosmetic)

### Section 1

Consider using lower case for `Establishing Relationships Between Sets`

### Section 5.1

Please use balanced quotes in `Type: 71 for "SRPOLICY-CAPABILITY TLV`

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

[Ballot discuss]
Here are a couple of topics that need a discussion with the authors/WG:

Sections 3.1 and 3.2

I would like to discuss some of the normative text related to the handling
of identifiers in this section. I am also sharing some suggestions based on my
understanding - please correct me, if I am wrong.

CURRENT
SR Policy Identifier MUST be the same for all SR Policy Candidate Paths in the
same SRPA.

SUGGEST
LSPs that represent Candidate Paths within an SR Policy MUST carry the
same SR Policy Identifiers (carried in Extended Association ID TLV) in their
SRPA.

CURRENT
SR Policy Identifier MUST be constant for a given SR Policy Candidate Path for
the lifetime of the PCEP session.

SUGGEST
LSPs that represent Candidate Paths within an SR Policy MUST NOT change their
SR Policy Identifiers for the lifetime of the LSP and the PCEP session.

Reason: While the PCEP session is still open, LSPs cannot "move" from one SR
Policy to another. Right? However, is it OK to transition from not having an
SRPA to having one or vice versa?

CURRENT
SR Policy Identifier MUST be different for different SRPAs.

What does this mean exactly? The SR Policy Indentifier is carried in the
Extended Association ID TLV and so it is part of the key of the Association
object. Isn't this obvious, can it be otherwise?

CURRENT
If the identifier is inconsistent among Candidate Paths, changes during the
lifetime of the PCEP session, or is not unique across different SRPAs, the
receiving PCEP speaker MUST send a PCEP Error (PCErr) message ...

I understand the part of changes (see my
suggestion above). But what is meant by "inconsistent" here? Also, I don't
understand the "not unique" part.

Similar questions for the blob below in 3.2

CURRENT
SR Policy Candidate Path Identifier MUST be constant for the lifetime of the
PCEP session. SR Policy Candidate Path Identifier MUST be different for
distinct Candidate Paths within the same SRPA. If SR Policy Candidate Path
Identifier changes during the lifetime of the PCEP session or is not unique
among distinct Candidate Paths, the PCEP speaker MUST send a PCErr message with
Error-Type = 26 "Association Error" and Error Value = 21 "SR Policy Candidate
Path Identifier Mismatch".   


Section 4.2.2

CURRENT
Originator Address: Represented as a 128-bit value as specified in Section 2.4
of [RFC9256]. When sending a PCInitiate message, the PCE is acting as the
originator and therefore MUST set this to an address that it owns.

Assume a dual/redundant PCE deployment. The use of MUST above will result in
double the number of LSPs at the PCC - one from each PCE. Is it possible to
use a common (anycast) IP address as the originator from each PCE while they
have their own/individual IP addresses for the session establishment? Perhaps
something to allow/enable as a configuration option? Is this something that
needs to be considered?

[Ballot comment]
I would also appreciate responses/updates for the following comments that are inline in the idnits format output for the v24 of the document.

120   Path Computation Element Communication Protocol (PCEP) Extensions for
121   Segment Routing [RFC8664] specifies extensions to the PCEP that allow
122   a stateful Path Computation Element (PCE) to compute and initiate
123   Traffic Engineering (TE) paths, as well as a Path Computation Client
124   (PCC) to request a path subject to certain constraints and
125   optimization criteria in SR networks.  Although PCEP extensions
126   introduced in [RFC8664] are defined for creation of SR-TE tunnels,

I didn't find RFC8664 using the term "SR-TE tunnels". Instead, it uses
the term "SR-TE paths".

127   these are not SR Policies and lack many important features described
128   in [RFC9256].

These "important features" are not listed in this document or anywhere
else. It would be good to list at least some of them as a bullet list to guide
readers on features that would be missed by an implementation/deployment that
is only supporting RFC8664/RFC9603.

Are there any backwards compatibility considerations for these
specifications as compared to RFC8664/9603? E.g., LSPs that were previously
reported without SRPA now start getting reported with the SRPA after a PCC
upgrade to a newer software version?



189   SR Policy LSP:  An LSP set up using Path Setup Type [RFC8408] 1
190       (Segment Routing) or 3 (SRv6).

The use of LSP (label switched path) for SRv6 sounds odd. I am aware
that the term LSP in integral to PCEP though. However, some clarification for
the term as done in section 2 of RFC9603 would be helpful.


192   SR Policy Association:  A new association type used to group
193       candidate paths belonging to same SR Policy.  Depending on the
194       discussion context, it can refer to the PCEP ASSOCIATION object of
195       SR Policy type or to a group of LSPs that belong to the
196       association.

[minor] Suggest to add BGP-LS here with the reference to the base RFC9552 as
informational due to use in section 4.2.2. I also found IGP and ERO acronyms.



198 3.  Overview

This section talks about the use of SRPA and error handling
while the SRPA is introduced in section 4. Could you please consider swapping
their order for better readability? OR moving the error handling portions
under the relevant sub-sections of section 4.


200   The SR Policy is represented by a new type of PCEP Association,
201   called the SR Policy Association (SRPA) (see Section 4).  The SR
202   Candidate Paths of an SR Policy are the LSPs within the same SRPA.

The correct term is 'SR Policy Candidate Path' and not 'SR Candidate
Path' per RFC9256. Please fix/correct in a few other places as well.

203   Encoding multiple Segment Lists within an SR Policy Candidate Path is
204   described in [I-D.ietf-pce-multipath].  These considerations are not
205   covered here.

Perhaps ... The extensions in this document specify the encoding of a
single segment list within an SR Policy Candidate Path. Encoding of multiple
segment lists is outside the scope of this document and specified in
[I-D.ietf-pce-multipath].


217 3.1.  SR Policy Identifier

219   SR Policy Identifier uniquely identifies an SR Policy [RFC9256]
220   within the network.  SR Policy identifier is assigned by PCEP peer

s/network/SR domain


492   Discriminator: 32-bit value that encodes the Discriminator of the
493   Candidate Path, as specified in Section 2.5 of [RFC9256].  This is
494   the field that mainly distinguishes different SR Candidate Paths,
495   coming from the same originator.  It is allowed to be any number in
496   the 32-bit range.

Perhaps ... it is a 32-bit unsigned integer value. This is also a more
general comment applicable in other similar places.


552 5.  SR Policy Signaling Extensions

554   This section introduces mechanisms that are described for SR Policies
555   in [RFC9256] to PCEP, but which do not make use of the SRPA for
556   signaling in PCEP.  Since SRPA is not used, there needs to be a
557   separate capability negotiation.

I found the above hard to parse. Is the intention here to state that
since PCEP extensions for SR-TE path signaling have been around and these are
new extensions for SR Policy signaling (compliant to [RFC9256]), there is a
need to introduce capability negotiations?


626 5.2.  Computation Priority TLV

Suggest 5.2 to be LSP Object TLVs and for 5.2 through 5.4 to
be indented under it. Or something similar, for clarity on the different types of
extensions.


628   The COMPUTATION-PRIORITY TLV (Figure 7) is an optional TLV for the
629   LSP object.  It is used to signal the numerical computation priority,
630   as specified in Section 2.12 of [RFC9256].  If the TLV is absent from
631   the LSP object and the P-flag in the SRPOLICY-CAPABILITY TLV is set
632   to 1, a default Priority value of 128 is used.

634       0                  1                  2                  3
635       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
636       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
637       |            Type              |            Length            |
638       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
639       |    Priority  |                  Reserved                    |
640       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

642                 Figure 7: COMPUTATION-PRIORITY TLV Format

644   Type: 68 for "COMPUTATION-PRIORITY" TLV.

646   Length: 4.

648   Priority: Numerical priority with which this LSP is to be recomputed
649   by the PCE upon topology change.  Lowest value is the highest
650   priority.

I assume 8-bit unsigned integer values? Is zero allowed?

652   Reserved: This field MUST be set to zero on transmission and MUST be
653   ignored on receipt.


907 6.4.  TE-PATH-BINDING TLV Flag field

909   An earlier version of this document added new bit within the "TE-
910   PATH-BINDING TLV Flag field" registry of the "Path Computation
911   Element Protocol (PCEP) Numbers" registry group, which was also early
912   allocated by the IANA.

914   IANA is requested to cancel the early allocation made which is not
915   needed anymore.  As per the instructions from the chairs, please mark
916   it as deprecated.

Suggest .. IANA is requested to mark the bit position as deprecated
as follows:

That said, I will leave it to the IANA team.


918   +------------+------------------------------------------+-----------+
919   | Bit position | Description                            | Reference |
920   +--------------+----------------------------------------+-----------+
921   | 1            | Deprecated (Specified-BSID-only)      | This.I-D  |
922   +--------------+----------------------------------------+-----------+



970 6.7.  SR Policy Capability TLV Flag field

972   This document requests IANA to maintain a new registry under "Path
973   Computation Element Protocol (PCEP) Numbers" registry group.  The new
974   registry is called "SR Policy Capability TLV Flag Field".  New values
975   are to be assigned by "IETF review" [RFC8126].  Each bit should be
976   tracked with the following qualities:

978   *  Bit (counting from bit 0 as the most significant bit).

980   *  Description.

982   *  Reference.

The section 5.1 has alphabetical identifiers for these bits. Strongly
suggest to retain the same in the IANA table below in addition to the
description.

984   +--------+-----------------------------------------------+-----------+
985   | Bit    | Description                                  | Reference |
986   +--------+-----------------------------------------------+-----------+
987   | 0 - 26 | Unassigned                                    | This.I-D  |
988   +--------+-----------------------------------------------+-----------+
989   | 27    | Stateless Operation                          | This.I-D  |
990   +--------+-----------------------------------------------+-----------+
991   | 28    | Unassigned                                    | This.I-D  |
992   +--------+-----------------------------------------------+-----------+
993   | 29    | Invalidation                                  | This.I-D  |
994   +--------+-----------------------------------------------+-----------+
995   | 30    | Explicit NULL Label Policy                    | This.I-D  |
996   +--------+-----------------------------------------------+-----------+
997   | 31    | Computation Priority                          | This.I-D  |
998   +--------+-----------------------------------------------+-----------+

< EoR v24 >

[Ballot comment]
Hi Samuel, all,

The changes in [1] fully address my previous DISCUSS/COMMENTs [2]. Thank you for carefully tracking all those. There are some few nits:

* Section 2: s/An LSP set up using/An LSP setup using
* Section 4: s/the ASSOCIATION object Section 6.1 of [RFC8697]/the ASSOCIATION object (Section 6.1 of [RFC8697])
* Section 5.14:

(1) s/If this flag is not set/If this flag is set to 0  (more than occurrence in the text)

(2)

  OLD:
  More flags can be assigned in the future per (Section 6.7)
 
  NEW: 
  More flags can be assigned in the future per (Section 6.7).

* Section 5.4.1: s/As stated in Section 8.1 of [RFC9256]1/As stated in Section 8.1 of [RFC9256]

As a general note (and I'm looking to the routing ADs :-)), I hope we can have an overview document that glue the various SR policy (and beyond) pieces in operations and go through to assess how these can be grafted together.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-24
[2] https://mailarchive.ietf.org/arch/msg/pce/zYWbTajJ943cNxLLySO6kCEaw4Q/

[Ballot comment]
Thanks to Joe Salowey for his secdir reviews.

One very small comment:

Abstract, para 2:  'bring up'?  what does this mean?  Are we bringing up protocols, like we raise children?  Or does it mean something else?

[Ballot comment]
## Section 3.1

Who assigns the id? Who ensures unicity?

## Section 4.1

(1)

CURRENT:
  *  Extended Association ID TLV: Mandatory TLV of the ASSOCIATION
      object. 

As that TLV is optional in rfc8697, I think the wording should be clear this is for SR policy context.

(2)

CURRENT: “Any others MUST be ignored”

Should we log this as well?


## Section 4.2.1

(1) Should we remind that padding is not included in the Length field?

CURRENT:
The TLV MUST be zero-padded so
  that the TLV is 4-octet aligned.

(2) “a string of printable ASCII characters”: We may cite STD80 here.

## Section 5

A more explicit title would be helpful.

BTW, the flow of the document would be better if we first introduce the capabilities/session establishment and then dive into SRPA signaling.

## Section 5.1

(1) Shouldn’t the following be conditioned by the activation to use the feature?

CURRENT:
  Implementations that support SR Policy MUST
  include SRPOLICY-CAPABILITY TLV in the OPEN object. 

(2) I guess that we should log the error as well. Please update.

CURRENT:
  If a PCEP speaker receives SRPA but the SRPOLICY-CAPABILITY TLV is
  not exchanged, then the PCEP speaker MUST send a PCErr message with
  Error- Type = 10 ("Reception of an invalid object") and Error-Value =
  TBD ("Missing SRPOLICY-CAPABILITY TLV") and MUST then close the PCEP
  session.

Also, consider updating similar constructs in the spec.

(3) Figure 6: Any reason non contiguous bits were used for these flags?

(4) The use of “PCEP speaker“ is confusing in some part of the text. Please make it clear whether this is about receiving or sending.

## Section 5.3

CURRENT:
  Note that Explicit
  Null is currently only defined for SR MPLS and not for SRv6.

Does it make sense for SRv6 at the first place?

Anyway, I would align the description with draft-ietf-idr-segment-routing-te-policy.

## Section 5.4

CURRENT:
  Oper: encodes the current state of the LSP, i.e., whether it is
  actively dropping traffic right now. 

A better description is needed to reflect the use of the oper status. You may consider deleting text till “i.e.,”.

## Section 6.1

The registry url should be provided instead of RFC8697.

## Section 6.5

Given that draft-ietf-idr-bgp-ls-sr-policy is in the RFC editor queue, may be it is time to delete this request.

## Section 9.6

First, thanks to you and the PCE WG to always supply a manageability section. That’s helpful.

There are bunch of extensions that are defined out there for SR policy purposes (BGP, for example). Should we consider including considerations about co-existence and interactions between those?

It is tempting to have a mapping between the various SR policy objects to make sure that feature parity (or no) is supported. I’m not asking to make any change to cover this mapping, but I would be happy If you consider so.

## References

I don’t think that I-D.ietf-idr-sr-policy-safi is normative. Please consider moving the entry to be listed as Informative given that the only citation is:

  The values of this field are
  specified in IANA registry "SR Policy ENLP Values" under "Segment
  Routing" registry group, which was introduced in Section 6.10 of
  [I-D.ietf-idr-sr-policy-safi].

You may replace delete “which was introduced in Section 6.10 of
  [I-D.ietf-idr-sr-policy-safi].” and replace it with a pointer to https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#sr-policy-enlp-values.

[Ballot comment]
Many abbreviated terms in the Introduction aren't defined until Section 2. (PCC, SR-TE, LSPs, etc.) Consider expanding these on first use. Further, several of the abbreviations expanded in Section 2 don't have references to the RFCs where the terms are specified. This makes it difficult to explore further. For example, PCC is defined in RFC5440 which is not referenced by this document until Section 6. Compare this to the Terminology section of RFC8231, which provides explicit sources for each term.

Throughout 3.x, should the names of these elements have "The" or "A" before them? Also, s/consist/consists/.

The sentence in the Acknowledgement lacks a subject. Who would like to thank these people?

[Ballot discuss]
Hi Mike, Siva, Samuel, Colby, Shuping, and Hooman,

Many thanks for the effort put into this specification.

Thanks also to Xiao for the opsdir review and to the authors for promptly addressing his comments.

Please find below some few DISCUSS points, with a focus to ensure that this spec is consistent with the other various pieces of work that covers this same topic.

## Section 3

CURRENT

  This document does not propose any extension for the use of BSID with
  SR Policy; the existing behavior is documented in [RFC9604].

Are there additional considerations to take into account when used with the new objects on this document? For example, the base spec says “Candidate paths of different SR Policies MUST NOT have the same BSID”, while such checks are not (at least I failed to find where) defined in 9604.

## Section 4.2.1

The SR policy BGP extension includes: “It is RECOMMENDED that the size of the symbolic name for the SR Policy is limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes when signaling via BGP”

I guess we should be consistent and align the various pieces, unless there are specifics to a given signaling mechanism.

This is even important given that some computed paths will be passed between the two signaling channels:

“Typically, but not limited to, an SR Policy is computed by a controller or a path computation engine (PCE) and originated by a BGP speaker on its behalf.”

## Section 4.2.2: SR Policy Candidate Path Name

The BGP extension has the following “It is RECOMMENDED that the size of the symbolic name for the candidate path is limited to 255 bytes. Implementations MAY choose to truncate long names to 255 bytes when signaling via BGP”

I guess we should be consistent.

[Ballot comment]
My full review can be found at:

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-pce-segment-routing-policy-cp-22-rev%20Med.pdf
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-pce-segment-routing-policy-cp-22-rev%20Med.doc

Only the main comments are echoed here. Please refer to the review for the full set of comment, suggested edits, nits.

## Section 3.1

Who assigns the id? Who ensures unicity?

## Section 4.1

(1)

CURRENT:
  *  Extended Association ID TLV: Mandatory TLV of the ASSOCIATION
      object. 

As that TLV is optional in rfc8697, I think the wording should be clear this is for SR policy context.

(2)

CURRENT: “Any others MUST be ignored”

Should we log this as well?


## Section 4.2.1

(1) Should we remind that padding is not included in the Length field?

CURRENT:
The TLV MUST be zero-padded so
  that the TLV is 4-octet aligned.

(2) “a string of printable ASCII characters”: We may cite STD80 here.

## Section 5

A more explicit title would be helpful.

BTW, the flow of the document would be better if we first introduce the capabilities/session establishment and then dive into SRPA signaling.

## Section 5.1

(1) Shouldn’t the following be conditioned by the activation to use the feature?

CURRENT:
  Implementations that support SR Policy MUST
  include SRPOLICY-CAPABILITY TLV in the OPEN object. 

(2) I guess that we should log the error as well. Please update.

CURRENT:
  If a PCEP speaker receives SRPA but the SRPOLICY-CAPABILITY TLV is
  not exchanged, then the PCEP speaker MUST send a PCErr message with
  Error- Type = 10 ("Reception of an invalid object") and Error-Value =
  TBD ("Missing SRPOLICY-CAPABILITY TLV") and MUST then close the PCEP
  session.

Also, consider updating similar constructs in the spec.

(3) Figure 6: Any reason non contiguous bits were used for these flags?

(4) The use of “PCEP speaker“ is confusing in some part of the text. Please make it clear whether this is about receiving or sending.

## Section 5.3

CURRENT:
  Note that Explicit
  Null is currently only defined for SR MPLS and not for SRv6.

Does it make sense for SRv6 at the first place?

Anyway, I would align the description with draft-ietf-idr-segment-routing-te-policy.

## Section 5.4

CURRENT:
  Oper: encodes the current state of the LSP, i.e., whether it is
  actively dropping traffic right now. 

A better description is needed to reflect the use of the oper status. You may consider deleting text till “i.e.,”.

## Section 6.1

The registry url should be provided instead of RFC8697.

## Section 6.5

Given that draft-ietf-idr-bgp-ls-sr-policy is in the RFC editor queue, may be it is time to delete this request.

## Section 9.6

First, thanks to you and the PCE WG to always supply a manageability section. That’s helpful.

There are bunch of extensions that are defined out there for SR policy purposes (BGP, for example). Should we consider including considerations about co-existence and interactions between those?

It is tempting to have a mapping between the various SR policy objects to make sure that feature parity (or no) is supported. I’m not asking to make any change to cover this mapping, but I would be happy If you consider so.

## References

I don’t think that I-D.ietf-idr-sr-policy-safi is normative. Please consider moving the entry to be listed as Informative given that the only citation is:

  The values of this field are
  specified in IANA registry "SR Policy ENLP Values" under "Segment
  Routing" registry group, which was introduced in Section 6.10 of
  [I-D.ietf-idr-sr-policy-safi].

You may replace delete “which was introduced in Section 6.10 of
  [I-D.ietf-idr-sr-policy-safi].” and replace it with a pointer to https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#sr-policy-enlp-values.

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few with no objections from others.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

WG debated the use of a fixed value for association ID (and innovative use of Extended Association ID) but converged on the current solution to handle any possibility of a race condition in case of multiple PCE. This has WG consensus behind it.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The chair has reviewed this document. The document is clear and ready
to be shipped.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension and thus the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. Poll was conducted during adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes. An additional author (Samuel) was added late in the process and took over the editor's pen because of affiliation changes. The five initial authors contributed the earlier text and Samuel handled the directorate and AD review. 

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 8231, it is captured in the metadata, abstract, and introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.
Some coordination is needed with draft-ietf-idr-bgp-ls-sr-policy & draft-ietf-idr-sr-policy-safi as these documents are trying to create the same registries. Whichever document gets to the IESG approval first keeps the registry and the other would need to update the IANA section. 


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-17.html#section-6.5
The guidance is the same as RFC 9256.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few with no objections from others.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

WG debated the use of a fixed value for association ID (and innovative use of Extended Association ID) but converged on the current solution to handle any possibility of a race condition in case of multiple PCE. This has WG consensus behind it.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The chair has reviewed this document. The document is clear and ready
to be shipped.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension and thus the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. Poll was conducted during adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes. An additional author (Samuel) was added late in the process and took over the editor's pen because of affiliation changes. The five initial authors contributed the earlier text and Samuel handled the directorate and AD review. 

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 8231, it is captured in the metadata and abstract.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.
Some coordination is needed with draft-ietf-idr-bgp-ls-sr-policy & draft-ietf-idr-sr-policy-safi as these documents are trying to create the same registries. Whichever document gets to the IESG approval first keeps the registry and the other would need to update the IANA section. 


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-17.html#section-6.5
The guidance is the same as RFC 9256.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pce-segment-routing-policy-cp-18. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are eight actions which we must complete.

First, in the ASSOCIATION Type Field registry in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the existing early allocation for Type: 6; Description SR Policy Association will be made permanent and its reference changed to [ RFC-to-be ].

Second, in the PCEP TLV Type Indicators also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the eight early allocations for the following type indicators will be made permanent and their references changed to [ RFC-to-be ]:

| 56 | SRPOLICY-POL-NAME
| 57 | SRPOLICY-CPATH-ID
| 58 | SRPOLICY-CPATH-NAME
| 59 | SRPOLICY-CPATH-PREFERENCE
| 68 | COMPUTATION-PRIORITY
| 69 | EXPLICIT-NULL-LABEL-POLICY
| 70 | INVALIDATION
| 71 | SRPOLICY-CAPABILITY

Third, in the PCEP-ERROR Object Error Types and Values TE-PATH-BINDING TLV Flag field also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the existing, temporary registrations for one new Error-Value within the "Mandatory Object Missing" Error-Type and two new Error-Values within the "Association Error" Error-Type will be made permanent and their references changed to [ RFC-to-be ]:

+------------+------------------+-----------------------+----------------+
| Error-Type | Meaning | Error-value | Reference |
+------------+------------------+-----------------------+----------------+
| 6 | Mandatory Object | | [RFC5440] |
| | Missing | | |
+------------+------------------+-----------------------+----------------+
| | | 21: Missing SR | [ RFC-to-be ] |
| | | Policy Mandatory TLV | |
+------------+------------------+-----------------------+----------------+
| 26 | Association | | [RFC8697] |
| | Error | | |
+------------+------------------+-----------------------+----------------+
| | | 20: SR Policy | [ RFC-to-be ] |
| | | Identifers Mismatch | |
+------------+------------------+-----------------------+----------------+
| | | 21: SR Policy | [ RFC-to-be ] |
| | | Candidate Path | |
| | | Identifier Mismatch | |
+------------+------------------+-----------------------+----------------+

Fourth, in the TE-PATH-BINDING TLV Flag field also in the Path Computation Element Protocol (PCEP) Numbers registry group located at:

https://www.iana.org/assignments/pcep/

the early allocation for Bit Position: 1; Description: S (Specified-BSID-only) will be made permanent and its reference changed to [ RFC-to-be ].

Fifth, a new registry is to be created called the SR Policy Protocol Origin registry. The new registry will be located in the Segment Routing registry group located at:

https://www.iana.org/assignments/segment-routing/

The new registry will be managed via Specification Required as defined in RFC8126. There are initial registrations in the new registry as follows:

+--------------+----------------------------------------+----------------+
| Value | Description | Reference |
+--------------+----------------------------------------+----------------+
| 0 | Reserved (not to be used) | [ RFC-to-be ] |
+--------------+----------------------------------------+----------------+
| 1-9 | Unassigned | [ RFC-to-be ] |
+--------------+----------------------------------------+----------------+
| 10 | PCEP (in PCEP) | [ RFC-to-be ] |
+--------------+----------------------------------------+----------------+
| 11-19 | Unassigned | [ RFC-to-be ] |
+--------------+----------------------------------------+----------------+
| 20 | BGP SR Policy (in PCEP) | [ RFC-to-be ] |
+--------------+----------------------------------------+----------------+
| 21-29 | Unassigned | [ RFC-to-be ] |
+--------------+----------------------------------------+----------------+
| 30 | Configuration (CLI, YANG model via | [ RFC-to-be ] |
| | NETCONF, etc.) (in PCEP) | |
+--------------+----------------------------------------+----------------+
| 31-250 | Unassigned | [ RFC-to-be ] |
+--------------+----------------------------------------+----------------+
| 251 - 255 | Private Use (not to be assigned by | [ RFC-to-be ] |
| | |ANA) | |
+--------------+----------------------------------------+----------------+

Sixth, another new registry is to be created called the SR Policy ENLP Values registry. The new registry will be located in the Segment Routing registry group located at:

https://www.iana.org/assignments/segment-routing/

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:

+----------+--------------------------------------------+----------------+
| Value | Description | Reference |
+----------+--------------------------------------------+----------------+
| 0 | Reserved (not to be used). | [ RFC-to-be ] |
+----------+--------------------------------------------+----------------+
| 1 | Push an IPv4 Explicit NULL label on an | [ RFC-to-be ] |
| | unlabeled IPv4 packet, but do not push an | |
| | IPv6 Explicit NULL label on an unlabeled | |
| | IPv6 packet. | |
+----------+--------------------------------------------+----------------+
| 2 | Push an IPv6 Explicit NULL label on an | [ RFC-to-be ] |
| | unlabeled IPv6 packet, but do not push an | |
| | IPv4 Explicit NULL label on an unlabeled | |
| | IPv4 packet. | |
+----------+--------------------------------------------+----------------+
| 3 | Push an IPv4 Explicit NULL label on an | [ RFC-to-be ] |
| | unlabeled IPv4 packet, and push an IPv6 | |
| | Explicit NULL label on an unlabeled IPv6 | |
| | packet. | |
+----------+--------------------------------------------+----------------+
| 4 | Do not push an Explicit NULL label. | [ RFC-to-be ] |
+----------+--------------------------------------------+----------------+
| 5 - 255 | Reserved. | [ RFC-to-be ] |
+----------+--------------------------------------------+----------------+

Seventh, another new registry is to be created called the SR Policy Invalidation Operational Flags registry. The new registry will be located in the Segment Routing registry group located at:

https://www.iana.org/assignments/segment-routing/

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:

+-------+-----------------------------------------------+----------------+
| Bit | Description | Reference |
+-------+-----------------------------------------------+----------------+
| 0 - 6 | Unassigned | [ RFC-to-be ] |
+-------+-----------------------------------------------+----------------+
| 7 | D: dropping - the LSP is currently attracting | [ RFC-to-be ] |
| | traffic and actively dropping it. | |
+-------+-----------------------------------------------+----------------+

Eighth, another new registry is to be created called the SR Policy Invalidation Configuration Flags registry. The new registry will be located in the Segment Routing registry group located at:

https://www.iana.org/assignments/segment-routing/

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:

+-------+-----------------------------------------------+----------------+
| Bit | Description | Reference |
+-------+-----------------------------------------------+----------------+
| 0 - 6 | Unassigned. | [ RFC-to-be ] |
+-------+-----------------------------------------------+----------------+
| 7 | D: drop enabled - the Drop-upon-invalid is | [ RFC-to-be ] |
| | enabled on the LSP. | |
+-------+-----------------------------------------------+----------------+

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-11-11):

From: The IESG
To: IETF-Announce
CC: dd@dhruvdhody.com, draft-ietf-pce-segment-routing-policy-cp@ietf.org, pce-chairs@ietf.org, pce@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Path Computation Element Communication
Protocol (PCEP) Extensions for
  Segment Routing (SR) Policy Candidate Paths'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-11-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Segment Routing (SR) allows a node to steer a packet flow along any
  path.  SR Policy is an ordered list of segments (i.e., instructions)
  that represent a source-routed policy.  Packet flows are steered into
  an SR Policy on a node where it is instantiated called a headend
  node.  An SR Policy is made of one or more candidate paths.

  This document specifies the Path Computation Element Communication
  Protocol (PCEP) extension to signal candidate paths of the SR Policy.
  Additionally, this document updates RFC 8231 to allow stateful bring
  up of an SR Label Switched Path (LSP), without using the path
  computation request and reply messages.  This document is applicable
  to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over
  IPv6 (SRv6).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few with no objections from others.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

WG debated the use of a fixed value for association ID (and innovative use of Extended Association ID) but converged on the current solution to handle any possibility of a race condition in case of multiple PCE.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This document has been reviewed by the chair. The document is clear and ready
to be shipped.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension and thus the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. Poll was conducted during adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 8231, it is captured in the metadata and abstract.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.
Some coordination is needed with draft-ietf-idr-bgp-ls-sr-policy as both documents are trying to create the same registry. Whichever document gets to the IESG approval first keeps the registry and the other would need to update the IANA section. 


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-17.html#section-6.5
The guidance is the same as RFC 9256.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few with no objections from others.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

WG debated the use of a fixed value for association ID (and innovative use of Extended Association ID) but converged on the current solution to handle any possibility of a race condition in case of multiple PCE.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This document has been reviewed by the chair. The document is clear and ready
to be shipped.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension and thus the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. Poll was conducted during adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 8231, it is captured in the metadata and abstract.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.
Some coordination is needed with draft-ietf-idr-bgp-ls-sr-policy as both documents are trying to create the same registry. Whichever document gets to the IESG approval first keeps the registry and the other would need to update the IANA section. 


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-17.html#section-6.5
The guidance is the same as RFC 9256.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few with no objections from others.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

WG debated the use of a fixed value for association ID (and innovative use of Extended Association ID) but converged on the current solution to handle any possibility of a race condition in case of multiple PCE.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This document has been reviewed by the chair. The document is clear and ready
to be shipped.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension and thus the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. Poll was conducted during adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

None

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.
Some coordination is needed with draft-ietf-idr-bgp-ls-sr-policy as both documents are trying to create the same registry. Whichever document gets to the IESG approval first keeps the registry and the other would need to update the IANA section. 


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-17.html#section-6.5
The guidance is the same as RFC 9256.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a strong concurrence of a few with no objections from others.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

WG debated the use of a fixed value for association ID (and instead innovative use of Extended Association ID) but converged on this solution to handle any possibility of a race condition in case of multiple PCE.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The Implementation Status section notes that there are 2 known implementations at the least.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This document has been reviewed by the chair. The document is clear and ready
to be shipped.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard
This I-D defines a protocol extension and thus the standards track makes sense.
All attributes in Datatracker are set correctly.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPRs. Poll was conducted during adoption and WGLC.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.


Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

None

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is consistent with the document's body and has been reviewed.
Some coordination is needed with draft-ietf-idr-bgp-ls-sr-policy as both documents are trying to create the same registry. Whichever document gets to the IESG approval first keeps the registry and the other would need to update the IANA section. 


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-17.html#section-6.5
The guidance is the same as RFC 9256.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/