Last Call Review of draft-ietf-pce-segment-routing-policy-cp-18
review-ietf-pce-segment-routing-policy-cp-18-genart-lc-sparks-2024-11-11-00

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

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

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.