Florian Obser: MAY use prefix delegation, or SHOULD?

[Abhayakara]

5.2.2 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.

https://mailarchive.ietf.org/arch/msg/snac/sEoT5x0TkxQ8EqlwWMYRV8ePXTU/

[Abhayakara]

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.

[Abhayakara]

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.

[Abhayakara]

Explain what to do if prefix is to narrow, and also if it is too wide.