Change:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?

Discussion:
If the first byte is alert(21), handshake(22), or ack(proposed, 25), the record MUST be interpreted as a DTLSPlaintext record. <del> If the first byte is any other other value, then receivers MUST check to see if the leading bits of the first byte are 001.  If so, the implementation MUST process the record as DTLSCiphertext; the true content type will be inside the protected portion. </del> <ins> If the first byte is any other value, then receivers MUST check to see if the leading bits of the first byte are 001.  If so, the implementation MUST process the record as DTLSCiphertext; the true content type will be inside the protected portion. </ins> Otherwise, the record MUST be rejected as if it had failed deprotection, as described in handling-invalid-records.

of the Mask with the sequence number.  Decryption is accomplished by the same process. <del> In some (rare) cases the ciphertext may be less than 16 bytes.  This cannot happen with most of the DTLS AEAD algorithms because the authentication tag itself is 16 bytes, however some algorithms such as TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag, and in combination with a short plaintext, the result might be less than 16 bytes.  In this case, implementations MUST pad the plaintext out (using the conventional record padding mechanism) in order to make a suitable-length ciphertext. </del> <ins> This procedure requires the ciphertext length be at least 16 bytes. Receivers MUST reject shorter records as if they had failed deprotection, as described in handling-invalid-records.  Senders MUST pad short plaintexts out (using the conventional record padding mechanism) in order to make a suitable-length ciphertext.  Note most of the DTLS AEAD algorithms have a 16-byte authentication tag and need no padding.  However, some algorithms such as TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag and may require padding for short inputs. </ins> Note that sequence number encryption is only applied to the DTLSCiphertext structure and not to the DTLSPlaintext structure,

An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its response to the victim machine, thus <del> flooding it.  Depending on the selected ciphersuite this response </del> <ins> flooding it.  Depending on the selected parameters this response </ins> message can be quite large, as it is the case for a Certificate message.

subsequently into a ClientHello message.  DTLS 1.2 on the other hand used a separate message, namely the HelloVerifyRequest, to pass a cookie to the client and did not utilize the extension mechanism. <del> For backwards compatibility reason the cookie field in the </del> <ins> For backwards compatibility reasons, the cookie field in the </ins> ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 compliant server implementation.

the deletion attacks that EndOfEarlyData prevents in TLS.  Servers SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 2 record and SHOULD NOT accept epoch 1 data after the first <del> epoch 3 record is received. </del> <ins> epoch 3 record is received.  (See dtls-epoch for the definitions of each epoch.) </ins> 5.6.

the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state. <del> The implementation reads a ACK from the peer: upon receiving an </del> <ins> The implementation reads an ACK from the peer: upon receiving an </ins> ACK for a partial flight (as mentioned in sending-acks), the implementation transitions to the SENDING state, where it retransmits the unacked portion of the flight, resets the

value at each retransmission, up to no less than the RFC 6298 maximum of 60 seconds.  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer <del> values.  Note that a 100 msec timer is recommend rather than the </del> <ins> values.  Note that a 100 msec timer is recommended rather than the </ins> 3-second RFC 6298 default in order to improve latency for time- sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be

ServerHello, and HelloRetryRequest. epoch value (1) is used for messages protected using keys derived <del> from client_early_traffic_secret.  This includes early data sent by the client and the EndOfEarlyData message. </del> <ins> from client_early_traffic_secret.  Note this epoch is skipped if the client does not offer early data. </ins> epoch value (2) is used for messages protected using keys derived from [sender]_handshake_traffic_secret.  Messages transmitted

not included in this category. epoch value (3) is used for payloads protected using keys derived <del> from the initial traffic_secret_0.  This may include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message). </del> <ins> from the initial [sender]_application_traffic_secret_0.  This may include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message). </ins> epoch value (4 to 2^16-1) is used for payloads protected using <del> keys from the traffic_secret_N (N>0). </del> <ins> keys from the [sender]_application_traffic_secret_N (N>0). </ins> Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message.