Change:
use an CONNECTION_CLOSE frame with an appropriate error code to signal closure. <del> If the connection has been successfully established, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. If the endpoint does not have Handshake keys, or it is not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames in an Initial packet.  If multiple packets are sent, they can be coalesced (see packet-coalesce) to facilitate retransmission. </del> <ins> When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame.  Generally, this means sending the frame in a packet with the highest level of packet protection to avoid the packet being discarded.  However, during the handshake, it is possible that more advanced packet protection keys are not available to the peer, so the frame MAY be replicated in a packet that uses a lower packet protection level. After the handshake is confirmed, an endpoint MUST send any CONNECTION_CLOSE frames in a 1-RTT packet.  Prior to handshake confirmation, the peer might not have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD send CONNECTION_CLOSE frames in an Initial packet. A client will always know whether the server has Handshake keys (see discard-initial), but it is possible that a server does not know whether the client has Handshake keys.  Under these circumstances, a server SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at least one of them is processable by the client.  These packets can be coalesced into a single UDP datagram (see packet-coalesce). </ins> 10.4.

Discussion:
Clarifies that if the server wants the client to process a connection close, it SHOULD send one in Initial and Handshake. It seemed odd to me to say MAY send a CONNECTION_CLOSE in Initial, so I changed that to a SHOULD. I can revert that and the other SHOULD, but I think the current PR makes more sense. Came up in discussion on and I believe may be necessary to fully address . If not, I can open another issue.
We might just delete this tomorrow, but this is strictly better than what we have now.
Isn't the rule here that you always send it in the highest level?
The intent is for the peer to be able to read the packet, thus the recommendation to use a lower level if you aren't sure that they have the right keys. If they have the right keys, then they will ignore the Initial packet, if they don't then it's better to signal the error than have them keep trying. I think that this is OK. Do you have a specific concern with this design? Or the specific text?
I'm not sure. It seems like there are two policies: Always use level N until you are sure that the other side has level N+1 Always use the highest level. I take you to be proposing the first of these, which, I believe, means "use the highest level where you have received packets from the peer in (or zero)". This text may say that, but all this stuff about certain is kind of hard to parse. Rather than making people reason it out, I think we should provide them with a clear rule (for instance the one above).
An endpoint could logically migrate to the next packet number space / encryption level for new transmissions while still keeping the previous level for retransmissions. If the connection dies before retransmission the peer might not be able to read latest crypto level even if this is where you normally send new data. It is easier and safer to send CLOSE on both channels rather than retransmitting the handshake history.
I will await a PR then.
I had to fix a bug in which Picoquic was sending a connection close in handshake while the peer would not have the handshake key when receiving the message... URL
Tokyo conclusion: the principle here is that we want to use the highest level we know the peer to be able to read.

Reassign to editorial to a) include this principle, and b) make the text clearer.
NAME NAME : This issue is marked editorial, but it's borderline design. The PR that fixes it () introduces 2119 language and behavior that is new. I'll remove the editorial tag, but I'm not marking it as design. Can you advise on what to do next?
Will triage as design. Thanks.
NAME ?
Yes? The proposal is to close with no action on the basis of text already incorporated in .
There wasn't a consensus call. Will do one next round.
Fixed by .
LGTM for the most part. A few minor suggestions.