Change:
Both for 0-RTT and 1-RTT. Give NST- and externally-provisioned PSKs more uniform treatment.
NAME ping? It would be good to get some resolution in this space, as it's somewhat relevant to URL
I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value, since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are.
NAME is there a path forward for this (e.g., does it need to go to the list)?
NAME I think this is generally good except for the SNI stuff which conflicts with PR , which we also need to resolve one way or another. What say we land this without those pieces and then when we we will know what to do
SGTM. Do you need me to adjust the patch?
Nah, I'll do it.
These actually just seem to make the SNI requirements clearer but no sharper, so merging.
The Early Data Indication section contains this sentence: The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK. This implies to me that you can only do 0-RTT where the PSK was established via an earlier connection. In external PSK this is not the case. I don't think this interpretation was the intention.
This is stale text from before we allowed 0-RTT with external PSK, IIRC.
Zero-RTT Data says: But 4.6.1. New Session Ticket Message says: For consistency, I would like to have the latter in Section 2.2 with the same style. Moreover, I would like to know where this differences of requirements come from.
I think 4.2.10 may be more appropriate than 2.2, as it is closer to where the server is doing the relevant processing.
Now 4.2.10 has clear requirements. So, why don't we remove the same requirement from 2.3? additional information MUST be provisioned to both parties:

Discussion:
See NSTMessage for the use of the max_early_data_size field. The parameters for the 0-RTT data (symmetric cipher suite, ALPN <del> protocol, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </del> <ins> protocol, etc.) are those associated with the PSK in use.  For externally established PSKs, the associated values are those provisioned along with the key.  For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </ins> For PSKs provisioned via NewSessionTicket, a server MUST validate that the ticket age for the selected PSK identity (computed by

In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the <del> following values are consistent with those negotiated in the connection during which the ticket was established. </del> <ins> following values are consistent with those associated with the selected PSK: </ins> <del> The TLS version number and cipher suite. </del> <ins> The TLS version number </ins> <del> The selected ALPN RFC7301 protocol, if any. </del> <ins> The selected cipher suite The selected ALPN RFC7301 protocol, if any The selected SNI (Section 3 of RFC6066) value, if any These requirements are a superset of those needed to perform a 1-RTT handshake using the PSK in question.  For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those negotiated in the connection during which the ticket was established. </ins> Future extensions MUST define their interaction with 0-RTT.

Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is <del> defined.  The server must ensure that it selects a compatible PSK (if </del> <ins> defined.  The server MUST ensure that it selects a compatible PSK (if </ins> any) and cipher suite. <ins> Each PSK is also associated with at most one Server Name Identification (SNI) value (Section 3 of RFC6066).  For PSKs established via the ticket mechanism (NSTMessage), this is the SNI value (if any) on the connection where the ticket was established. For externally established PSKs, the associated SNI value (or lack of value) is set when the PSK is established.  The server MUST ensure that it selects a compatible PSK (if any) and SNI value (if any). SNI MUST NOT be negotiated when using a PSK not associated with an SNI value. </ins> Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs

use each ticket no more than once, with more recent tickets being used first. <del> Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection, and only if the client provides the same SNI value as in the original connection, as described in Section 3 of RFC6066. </del> <ins> Any ticket MUST only be resumed on connections where the following values match the values negotiated in the connection during which the ticket was established: The KDF hash algorithm associated with the cipher suite The SNI value (if any), as described in Section 3 of </ins> Note: Although the resumption master secret depends on the client's second flight, servers which do not request client authentication MAY