[Pce] Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions

[Dhruv Dhody <[e-mail]>]

Hi Authors,

I have done the Shepherd review of the I-D. Once the update is posted, I
will send this to the AD.

# Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions

## Minor
- Abstract uses the term "distinct hop requirements" where the term is not
used anywhere in this or SPRING document.

- In "[RFC8664] introduces the concept of Segment Routing Policy (SR
Policy)" - this should be RFC 9256. If you want to talk about RFC 8664, say
that it introduces SR to PCEP.

- Section 2, also add SR terms like SR Policy, SID etc

- Section 3, directly jumps to extension. It would benefit from some
initial summary text before all the details, example -
````
This section specifies the PCEP extensions that enable a PCC and PCE to
support Circuit-Style (CS) SR policies.  These extensions build on the
base PCEP [RFC5440], the Stateful PCE extensions [RFC8231], and the
Segment Routing (SR) Policy extensions [RFC9603].  The mechanisms defined
here allow a PCC or PCE to:

  * indicate the requirement for strict paths,
  * signal path persistency by disabling recomputation for specific paths,
  * identify and control behavior specific to Circuit-Style SR policies.

Unless explicitly stated, the procedures of existing PCEP messages and
objects remain unchanged.  The following subsections describe the specific
object formats, TLVs, and flag definitions introduced to realize this
functionality.
````

- Figure 1, shift the numbers 0,1,2... to right by 1 space, they need to
correspond to - and not +

- Section 3.3, this text - "If this flag is cleared, then the PCE SHOULD
recompute the path if the original path is invalidated."; can we add
'according to local policy' as we use in other PCE RFC? Also in section
4.2, you use MAY for this flag, be consistent.

- Section 4.1, no need to use BCP14's MAY in "Existing O flag in RP object
MAY be used to indicate similar behavior in PCReq and PCRep messages as
described in as described in Section 7.4.1 of [RFC5440]." as this is about
existing behavior. Further "If the O flag is set to 1 for both stateful and
stateless messages for SR paths introduced in [RFC8664]...", this is
unclear to me. Why both..and? Suppose the O flag in RP was not set during
PCReq but set in PCRpt in TLV would the PCE not process it?

- Section 4.2, "The presence of the TLV blocks path recomputation.." is
conflicting with Section 3.3 "the PCE MUST NOT recompute the path in cases
specified by flags.." - I think flags need to be set to block recomputation
and it should not be just the presence of the TLV.

- Section 4.2, "For example, if the same path can be encoded using
Adjacency, Binding, Prefix, or other SIDs, then PCE MAY switch between
various representations of the same path", the use of MAY inside a sentence
that starts for example, is not ideal.

- Section 4.2, "The only exception is an explicit request from the operator
to recompute the path." it would be clearer to explicitly state how
operator request recomputation.

- Section 4.2, do we need error handling in case the flags are set but PCE
still tries to recompute/update a new path?


## Nits
- s/This document proposes a set of extensions/This document specifies a
set of extensions/

- s/[RFC8664] introduces the concept of Segment Routing Policy (SR Policy)

Thanks!
Dhruv