ECH guidance conflicts with ECH-SVCB

[bemasc]

The current draft says

If the client supports TLS Encrypted Client Hello (ECH) discovery through SVCB records {{!SVCB-ECH=I-D.ietf-tls-svcb-ech}}, depending on the client's preference to handle ECH, the client SHOULD sort addresses with ECH keys taking priority to maintain privacy when attempting connection establishment.

ECH-SVCB says

A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack ... This configuration is NOT RECOMMENDED. Zone owners who do use such a mixed configuration SHOULD mark the RRs with "ech" as more preferred (i.e. lower SvcPriority value) than those without, in order to maximize the likelihood that ECH will be used in the absence of an active adversary.

In essence, there is a discrepancy as to whose responsibility it is to prioritize ECH.

I think the ECH-SVCB view should probably prevail.

Philosophically, the client cannot make the service more secure than the operator intends it to be.

Operationally, it seems valuable to be able to test ECH by placing it on a less-used, lower-priority endpoint, and it would be very surprising to discover that this effectively inverts the stated priority for some (large?) segment of clients.