Draft: draft-ietf-tls-dtls13

Commentary: LGTM with these changes .
Paragraph (version A):
TLS relies on an implicit sequence number on records.  If a record
is not received, then the recipient will use the wrong sequence
number when attempting to remove record protection from subsequent
records.  DTLS solves this problem by adding sequence numbers.
Paragraph (version A):
The TLS handshake is a lock-step cryptographic handshake.
Messages must be transmitted and received in a defined order; any
other order is an error.  DTLS handshake messages are also
assigned sequence numbers to enable reassembly in the correct
order in case datagrams are lost or reordered.
Paragraph (version B):
TLS relies on an implicit sequence number on records.  If a record
is not received, then the recipient will use the wrong sequence
number when attempting to remove record protection from subsequent
records.  DTLS solves this problem by adding sequence numbers to
records.
Paragraph (version B):
The TLS handshake is a lock-step cryptographic protocol.  Messages
must be transmitted and received in a defined order; any other
order is an error.  The DTLS handshake includes message sequence
numbers to enable reassembly in the correct order in case
datagrams are lost or reordered.
Paragraph (version A):
Datagram transport protocols, like UDP, are susceptible to abusive
behavior effecting denial of service attacks against
nonparticipants.  DTLS adds a return-routability check that uses
the TLS HelloRetryRequest message (see dos for details).
Paragraph (version B):
Datagram transport protocols, like UDP, are susceptible to abusive
behavior effecting denial of service attacks against
nonparticipants.  DTLS adds a return-routability check and DTLS
details).
Paragraph (version A):
The unified_hdr is a field of variable length, as shown in
cid_hdr.
Paragraph (version A):
The three high bits of the first byte of the DTLSCiphertext header
are set to 001.  This ensures that the value will fit within the
DTLS region when multiplexing is performed as described in
RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3
records from encrypted DTLS 1.2 records is possible when they are
carried on the same host/port quartet; such multiplexing is only
possible when CIDs I-D.ietf-tls-dtls-connection-id are in use, in
which case DTLS 1.2 records will have the content type tls12_cid
(25).
Paragraph (version B):
The unified header (unified_hdr) is a structure of variable
length, as shown in cid_hdr.
Paragraph (version B):
The three high bits of the first byte of the unified header are
set to 001.  This ensures that the value will fit within the DTLS
region when multiplexing is performed as described in RFC7983.  It
also ensures that distinguishing encrypted DTLS 1.3 records from
encrypted DTLS 1.2 records is possible when they are carried on
the same host/port quartet; such multiplexing is only possible
when CIDs I-D.ietf-tls-dtls-connection-id are in use, in which
case DTLS 1.2 records will have the content type tls12_cid (25).
Paragraph (version A):
hdr_examples illustrates different record layer header types.
Paragraph (version B):
hdr_examples illustrates different record headers.