Original text:
not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure- <del> provided NAT64 will not work.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </del>  5.3.

Reviewer comments:
states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. URL
Esko adds: What about the case where DHCPv6-PD is available, but the stub router doesn’t get the desired prefix length or encounters some error in the process? In that exceptional case it still MAY allocate a prefix out of its ULA prefix. Depending on the reader, “is available” and “works for me” can be different things.
My suggestion: Right, MAY would be way too unspecific in that case. MAY basically says "we aren't saying you shouldn't do this, nor that you mustn't do this." :) So I think as you say that what we really need here is to be more specific about exactly what "is available" means. So, perhaps: If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using IPv6 prefix delegation. and Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6-PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix.
Explain what to do if prefix is to narrow, and also if it is too wide. states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. In my defence, I have been left unsupervised.

Revised text:
not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure-  <ins> provided NAT64 will not work.  Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6 PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix. A stub router SHOULD request stub network prefixes with length 64. If the stub router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros. If the stub router obtains a prefix with length greater than 64, the stub router MUST treat the prefix as unusable and allocate a prefix out of its ULA prefix instead. </ins> 5.3.