Change:
We don't want to prohibit the use of long headers in other versions - in case they want to share the stateless reset design, but there is no sense in sending long headers.
While I agree with the issue, the PR says that other versions might want to reset with a long header and therefore the receiver must inspect long headers anyway. I can see this, but given that, I think it is pointless to require the current version to only send resets for short headers. A general advice ought to suffice since the MUST is not enforceable anyway.
The requirement exists to protect those packets from detection.
Please don't close issues until AFTER consensus is declared (not just called).
I suspect Martin was confused because this issue was tagged has-proposal 15 days ago.
Right. The trigger is , not .
But it's understandable Martin would have assumed this was one of the issues that was sent out in the batch of issues a week and a half ago, given this has been tagged with has-proposal for 15 days.

Discussion:
unpredictable values.  The last 16 bytes of the datagram contain a Stateless Reset Token. <del> An endpoint that receives a packet where removal of packet protection fails MUST check the last 16 bytes of that packet.  If the last 16 bytes of the packet are identical to a stateless reset token corresponding to a packet that was recently sent, the endpoint MUST NOT send any further packets; all state for the connection can then be discarded. </del> To entities other than its intended recipient, a stateless reset will be appear to be a packet with a short header.  For the packet to appear as valid, the Unpredictable Bits field needs to include at

functions defined in QUIC-TLS, packets that are smaller than 21 bytes are never valid. <ins> Endpoints MUST send stateless reset packets formatted as a packet with a short header.  However, endpoints MUST treat any packet ending in a valid stateless reset token as a stateless reset, as other QUIC versions might allow the use of a long header. </ins> An endpoint MAY send a stateless reset in response to a packet with a <del> long header.  This would not be effective if the stateless reset token was not yet available to a peer.  In this QUIC version, packets with a long header are only used during connection establishment. Because the stateless reset token is not available until connection establishment is complete or near completion, ignoring an unknown packet with a long header might be more effective. </del> <ins> long header.  Sending a stateless reset is not effective prior to the stateless reset token being available to a peer.  In this QUIC version, packets with a long header are only used during connection establishment.  Because the stateless reset token is not available until connection establishment is complete or near completion, ignoring an unknown packet with a long header might be as effective than sending a stateless reset. </ins> An endpoint cannot determine the Source Connection ID from a packet with a short header, therefore it cannot set the Destination

10.4.1. <del> An endpoint detects a potential stateless reset when a incoming packet with a short header either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet. The endpoint then compares the last 16 bytes of the packet with the Stateless Reset Token provided by its peer, either in a NEW_CONNECTION_ID frame or the server's transport parameters.  If these values are identical, the endpoint MUST enter the draining period and not send any further packets on this connection.  If the </del> <ins> An endpoint detects a potential stateless reset when an incoming packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet.  The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset Tokens that are associated with connection IDs that are currently in use.  This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired. If the last 16 bytes of the packet values are identical to a Stateless Reset Token, the endpoint MUST enter the draining period and not send any further packets on this connection.  If the </ins> comparison fails, the packet can be discarded. 10.4.2.

Revealing the Stateless Reset Token allows any entity to terminate the connection, so a value can only be used once.  This method for choosing the Stateless Reset Token means that the combination of <del> connection ID and static key cannot occur for another connection.  A denial of service attack is possible if the same connection ID is </del> <ins> connection ID and static key MUST NOT be used for another connection. A denial of service attack is possible if the same connection ID is </ins> used by instances that share a static key, or if an attacker can cause a packet to be routed to an instance that has no state but the same static key (see reset-oracle).  A connection ID from a <del> connection that is reset by revealing the Stateless Reset Token cannot be reused for new connections at nodes that share a static key. </del> <ins> connection that is reset by revealing the Stateless Reset Token MUST NOT be reused for new connections at nodes that share a static key. </ins> Note that Stateless Reset packets do not have any cryptographic protection.