Original text:
epoch and sequence number fields in the DTLSCiphertext structure have been reduced. <del> The DTLSCiphertext structure is a variable length header. </del>  Note that the DTLS 1.3 record layer is different from the DTLS 1.2 record layer. Identical to the encrypted_record field in a TLS 1.3 record. <del> 14 bit sequence number field. </del>  Identical to the length field in a TLS 1.3 record. (though they MUST be ACKed as usual). Endpoints MUST NOT send either of these messages if they did not <del> negotiate a connection ID. 10. Application data messages are carried by the record layer and are fragmented and encrypted based on the current connection state.  The messages are treated as transparent data to the record layer. </del>  <del> 11. </del>  Below is an example exchange for DTLS 1.3 using a single connection id in each direction. Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages. <del> 12. </del>  Security issues are discussed primarily in I-D.ietf-tls-tls13. DTLS client, such as the client certificate, less information is available to an on-path adversary. <del> 13. </del>  Since TLS 1.3 introduces a large number of changes to TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this Sequence numbers are encrypted. <del> 14. </del>  IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type

Reviewer comments:
This pull request aims to address the open issues regarding sequence number encryption. The approach chosen follows the design used in QUIC.

Revised text:
epoch and sequence number fields in the DTLSCiphertext structure have been reduced.  <ins> The DTLSCiphertext structure has a variable length header. </ins> Note that the DTLS 1.3 record layer is different from the DTLS 1.2 record layer. Identical to the encrypted_record field in a TLS 1.3 record.  <ins> The DTLSCiphertext header is tightly bit-packed, as shown below: The low order two bits of the epoch. The low order 14 bits of the record sequence number. </ins> Identical to the length field in a TLS 1.3 record. (though they MUST be ACKed as usual). Endpoints MUST NOT send either of these messages if they did not  <ins> negotiate a connection ID.  If an implementation receives these messages when connection IDs were not negotiated, it MUST abort the connection with an unexpected_message alert. </ins>  <ins> 9.1. </ins> Below is an example exchange for DTLS 1.3 using a single connection id in each direction. Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages.  <ins> 10. Application data messages are carried by the record layer and are fragmented and encrypted based on the current connection state.  The messages are treated as transparent data to the record layer. 11. </ins> Security issues are discussed primarily in I-D.ietf-tls-tls13. DTLS client, such as the client certificate, less information is available to an on-path adversary.  <ins> 12. </ins> Since TLS 1.3 introduces a large number of changes to TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this Sequence numbers are encrypted.  <ins> 13. </ins> IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type