Change:
Changes to explain Padding == PADDING Frame
Thanks again Gorry.
I have a long comment on a scattered observation that could be very simple to fix: In section 6, it wasn’t clear what were the ways that "padding" could be performed. There could be various ways - simply leave UDP payload unused, fill it with coalesced QUIC packets, add padding and other frames, etc and when the text says this I think it’s unclear to me what is expected - any or all of these, but it doesn't seem to be said. e.g.: /Clients that support multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support. / Is the assumption here, more like: /Clients that support multiple QUIC versions SHOULD coalesce QUIC packets or add PADDING frames to pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support. / … rather than some other technique to pad-out the datagram payload? See also: /Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary. A client that sends padded datagrams allows the server to send more data prior to completing address validation./ and later: /In particular, an endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum Transfer Unit (PMTU) discovery / So, I think the topic of padding needs a tiny bit more clarification - it’s almost there, but maybe a sentence that explicitly explains the permitted options in section 14 would be good, which could be cited rather than this scattered mention of “pad-out”
Perhaps these mentions of the word "padding" just need to reference section 19.1. "PADDING Frames" ?
Yes a REF is good: If that is all that is intended, we should say so.
Agreed, I think the right phrasing is PADDING Frames, though I don't think we need to reference 19.1 in every spot we talk about PADDING frames.
So could we grep for Padding and ensure we say /PADDING Frame/? - I guess the REF first time used would be good - if not already there?
How about something like: PR ?
Closing now that we have .
The commas for parentheticals got a little awkward there. Otherwise, this is a good change.I've done a bit of editorializing, and this LGTM. NAME should take a look.

Discussion:
The size of the first packet sent by a client will determine whether a server sends a Version Negotiation packet.  Clients that support <del> multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support.  This ensures that the server responds if there is a </del> <ins> multiple QUIC versions SHOULD ensure that the first UDP datagram they send is sized to the largest of the minimum datagram sizes from all versions they support, using PADDING frames (frame-padding) as necessary.  This ensures that the server responds if there is a </ins> mutually supported version.  A server might not send a Version Negotiation packet if the datagram it receives is smaller than the minimum size specified in a different version; see initial-size.

that contain packets that are all discarded. Clients MUST ensure that UDP datagrams containing Initial packets <del> have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary.  A client that sends padded datagrams allows the server to send more data prior to completing address validation. </del> <ins> have UDP payloads of at least 1200 bytes, adding PADDING frames as necessary.  A client that sends padded datagrams allows the server to send more data prior to completing address validation. </ins> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake

The resulting minimum size of 21 bytes does not guarantee that a stateless reset is difficult to distinguish from other packets if the recipient requires the use of a connection ID.  To achieve that end, <del> the endpoint SHOULD pad all packets it sends to at least 22 bytes longer than the minimum connection ID that it might request the peer to include in packets that the peer sends.  This ensures that any stateless reset sent by the peer is indistinguishable from a valid packet sent to the endpoint.  An endpoint that sends a stateless reset in response to a packet that is 43 bytes or shorter SHOULD send a stateless reset that is one byte shorter than the packet it responds to. </del> <ins> the endpoint SHOULD ensure that all packets it sends are at least 22 bytes longer than the minimum connection ID length that it requests the peer to include in its packets, adding PADDING frames as necessary.  This ensures that any stateless reset sent by the peer is indistinguishable from a valid packet sent to the endpoint.  An endpoint that sends a stateless reset in response to a packet that is 43 bytes or shorter SHOULD send a stateless reset that is one byte shorter than the packet it responds to. </ins> These values assume that the Stateless Reset Token is the same length as the minimum expansion of the packet protection AEAD.  Additional