MT review comments

draft-ietf-quic-tls.md

@@ -579,10 +579,10 @@ ClientHello spans multiple Initial packets, such servers would need to buffer
 the first received fragments, which could consume excessive resources if the
 client's address has not yet been validated.  To avoid this, servers MAY use
 the Retry feature (see Section 8.1 of {{QUIC-TRANSPORT}}) to only buffer
-partial ClientHello messages from clients with a validated address.  Though a packet
-larger than 1200 bytes might be supported by the path, a client improves the
-likelihood that a packet is accepted if it ensures that the first ClientHello
-message is small enough to stay within this limit.
+partial ClientHello messages from clients with a validated address.  Though a
+packet larger than 1200 bytes might be supported by the path, a client improves
+the likelihood that a packet is accepted if it ensures that the first
+ClientHello message is small enough to stay within this limit.
 
 QUIC packet and framing add at least 36 bytes of overhead to the ClientHello
 message.  That overhead increases if the client chooses a connection ID without

draft-ietf-quic-transport.md

@@ -1298,15 +1298,6 @@ properties:
 * authenticated negotiation of an application protocol (TLS uses ALPN
   {{?RFC7301}} for this purpose)
 
-The first CRYPTO frame from a client MUST be sent in a single packet.  Any
-second attempt that is triggered by address validation (see
-{{validate-handshake}}) MUST also be sent within a single packet. This avoids
-having to reassemble a message from multiple packets.
-
-The first client packet of the cryptographic handshake protocol MUST fit within
-a 1232 byte QUIC packet payload.  This includes overheads that reduce the space
-available to the cryptographic handshake protocol.
-
 An endpoint can verify support for Explicit Congestion Notification (ECN) in the
 first packets it sends, as described in {{ecn-validation}}.
 
@@ -3959,16 +3950,13 @@ Initial packet containing other frames can either discard the packet as spurious
 or treat it as a connection error.
 
 The first packet sent by a client always includes a CRYPTO frame that contains
-the entirety of the first cryptographic handshake message.  This packet, and the
-cryptographic handshake message, MUST fit in a single UDP datagram (see
-{{handshake}}).  The first CRYPTO frame sent always begins at an offset of 0
-(see {{handshake}}).
+the start of the first cryptographic handshake message.  The first CRYPTO frame
+sent always begins at an offset of 0 (see {{handshake}}).
 
-Note that if the server sends a HelloRetryRequest, the client will send a second
+Note that if the server sends a HelloRetryRequest, the client will send another
 Initial packet.  This Initial packet will continue the cryptographic handshake
 and will contain a CRYPTO frame with an offset matching the size of the CRYPTO
-frame sent in the first Initial packet.  Cryptographic handshake messages
-subsequent to the first do not need to fit within a single UDP datagram.
+frame sent in the first Initial packet.
 
 #### Abandoning Initial Packets {#discard-initial}