[Pce] Re: Opsdir telechat review of draft-ietf-pce-segment-routing-policy-cp-22

["Samuel Sidor (ssidor)" <[e-mail]>]

Thanks a lot Xiao for your review.

Please find updated version attached based on your comments (and based on new registry already created in spring "SR Policy Protocol Origin" by I-D.ietf-idr-bgp-ls-sr-policy, so our IANA section for that field is not needed anymore).

For interaction between SVEC and SRPA association type - there is no new relationship (both can coexist), so this case does not belong into "if any" part of that statement same way like for example RFC 9005 (introducing Policy association type), RFC 9059 (introducing bidirectional association) or RFC 9358 (VN association type).

Thanks,
Samuel

-----Original Message-----
From: Xiao Min via Datatracker <[e-mail]> 
Sent: Monday, March 24, 2025 3:44 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Opsdir telechat review of draft-ietf-pce-segment-routing-policy-cp-22

Reviewer: Xiao Min
Review result: Ready

Summary: I have been asked to review this draft on behalf of the OPS directorate. I think this document is READY.

Also, I have a few editorial comments for the authors to consider.

Section 1 & 3, it appears "PCEP LSP" or "PCEP LSPs" is not used in other PCE documents, so suggest to do s/PCEP LSP/LSP and s/PCEP LSPs/LSPs. Section 2, s/candidate paths belonging to the SR Policy/candidate paths belonging to the same SR Policy. Section 5.2, Figure 7, how long is the "Priority" field? 8 bits or 9 bits? I believe it's 8 bits. Section 5.3, Figure 8, how long is the "ENLP"
field? I believe it's 8 bits. In Section 3.2 of RFC 8697 it says "PCEP extensions that define a new Association Type should clarify the relationship between the SVEC object and the Association Type, if any", so some clarification text may be added.