Draft: draft-ietf-quic-transport

Commentary: 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 . 
 Is n'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 are n't sure that they have the right keys . If they have the right keys , then they will ignore the Initial packet , if they do n'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 ... 
 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 . 
 : 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 . 
 ? 
 Yes ? The proposal is to close with no action on the basis of text already incorporated in . 
 There was n't a consensus call . Will do one next round . 
 Fixed by . 
 LGTM for the most part . A few minor suggestions .
Paragraph (version A):
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.