I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-pce-segment-routing-policy-cp-18 Reviewer: Robert Sparks Review Date: 2024-11-11 IETF LC End Date: 2024-11-11 IESG Telechat date: Not scheduled for a telechat Summary: Ready but with issues to address before publication as a Proposed Standard RFC Issues: The document should have a top level section titled "Updates to RFC 8231". The updates can be moved to that section, or they can be summarized with a pointer added to the current section 5.6. The language in the IANA considerations section is all still about early allocation. It should be adjusted to reflect what is being asked of IANA as this document goes through the RFC publication process. The notes to the RFC editor to remove sections from the IANA considerations are unclear in their scope. Please identify exactly what to remove more clearly. There are many SHOULD requirements that are bare and without explanation. In particular, "SHOULD be a string of printable ASCII characters, without a NULL terminator" is problematic. Is it OK is someone uses some other encoding? What happens if there are NULLs? It would help to discuss _why_ the fields that are carrying this information and how it is expected to be used. One quick way to resolve this issue is to change these SHOULDs to MUSTs. Why is "When this flag is cleared, or when the SRPOLICY-CAPABILITY TLV is absent, the given peer SHOULD NOT be sent PCReq/PCRep messages for SR Policy LSPs" a SHOULD? What happens if the peer _does_ send those messages? I suggest rewriting the negative conditions (like "When these rues are not satisfied") with something explicit and positive. The phrase "these rules" is not precise. Please point to the place in the base specifications that define byte and bit ordering (so that high-order bit is unambiguous) and that defines how to zero-pad or make them explicit in this document. Nits/editorial comments: The document is acronym-rich and doesn't expand acronyms on their first use. The phrase "bring up" appears a couple of times, but is unclear and I haven't found it defined in the base documents. Is there a more rigorous phrase that could be used instead? In the introduction, 2nd paragraph, last sentence: RFCs don't create tunnels. Please adjust the sentence to identify the correct actor. Section 3.2, first paragraph, second sentence at "during its lifetime". The antecedent for its is ambiguous. Section 4.1, 4th list bullet, third sentence (starting with MUST). There's a word or phrase missing before MUST here. Micro-nit: Section 5.4.1, consider removing the word "essentially". Micro-nit: The table presentation in section 6.3 isn't necessary - it eats space and risks confusion. Consider a nested dictionary-list style presentation instead.