Original text:
4. <del> The DTLS record layer is similar to that of TLS 1.3 unless noted otherwise.  The only change is the inclusion of an explicit epoch and sequence number in the record.  This sequence number allows the recipient to correctly verify the TLS MAC.  The DTLS record format is shown below: </del>  The content type of the record. Identical to the encrypted_record field in a TLS 1.3 record.  4.1. DTLS uses an explicit sequence number, rather than an implicit one, Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association.  4.2. Each DTLS record MUST fit within a single datagram.  In order to

Reviewer comments:
NAME PTAL
Oops. Thanks.
Sorry, I forgot to mention that I plan to do a separate PR for shrinking DTLS ciphertext. I have part of it in my buffer, but got this up and had to move on to something else for a bit.
I'm happy to defer fixing KeyUpdate, which is basically non-functional as it is. This is fine on that basis.

Revised text:
4.  <ins> The DTLS record layer is similar to that of TLS 1.3.  There are two major changes: The DTLS record layer includes an explicit epoch and sequence number in the record.  This sequence number allows the recipient to correctly verify the TLS MAC. DTLS adds a short header format that can be used to reduce overhead once the handshake is complete. The basic DTLS record format is shown below: </ins> The content type of the record. Identical to the encrypted_record field in a TLS 1.3 record. <ins> As with previous versions of DTLS, mutliple DTLSCiphertext records can be included in the same underlying transport datagram. The short DTLS header format is: The short_epoch_and_sequence document contains the epoch and sequence packed into a 16 bit integer as follows: The first three bits are set to 001 in order to allow multiplexing between DTLS and VoIP protocols (STUN, RTP/RTCP, etc.)  RFC7983 and distinguish the short from long header formats. The fourth bit is the low order bit of the epoch value. The remaining bits contain the low order 12 bits of the sequence number. For deprotecion purposes, the nonce is computed using the full sequence number, which can be reconstructed as described in reconstructing. In this format, the length field is omitted and therefore the record consumes the entire rest of the datagram in the lower level transport.  It is not possible to have multiple DTLSShortCiphertext format records in the same datagram. DTLSShortCiphertext MUST only be used for data which is protected with one of the application_traffic_secrets, and not for either handshake or early data.  When using an application_traffic_secret for message protection, Implementations MAY use either DTLSCiphertext or DTLSShortCiphertext at their discretion. </ins> 4.1. DTLS uses an explicit sequence number, rather than an implicit one, Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. <ins> 4.1.1. Implementations can distinguish the two header formats by examining the first byte, which in the DTLSCiphertext header represents the content type.  The only valid values for the content type are alert(21), handshake(22), application_data(23), and ack(25), with application_data actually representing protected data with the true content type being encrypted.  If any of these values is present, then the record MUST be handled as DTLSCiphertext. 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, they MUST process the record as DTLSShortCiphertext.  Otherwise, the record MUST be rejected as if it had failed deprotection. 4.1.2. When receiving a DTLSShortCiphertext message, the recipient does not have a full epoch or sequence number value and so there is some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. If the epoch bit has the same parity as the current epoch, then implementations SHOULD reconstruct the sequence number by computing the full sequence number which is numerically closest to one plus the sequence number of the highest successfully deprotected record. If the epoch bit has a different parity from the current epoch, then the record is either from a previous epoch or from a future epoch. Implementations SHOULD use the epoch value which would produce a sequence number which is numerically closest to what would be reconstructed for that epoch, as determined by the algorithm in the paragraph above. [[OPEN ISSUE: Say something about how many outstanding packets? Difficulty here is that we have no ACKs to tell us what's outstanding.]] [[OPEN ISSUE: This isn't going to work well with multiple key updates.  There are a number of options here, including limiting to one outstanding update, or saying that you have to use long headers in that case.]] </ins> 4.2. Each DTLS record MUST fit within a single datagram.  In order to