Original text:
datagrams are often limited to less than 1500 bytes if IP fragmentation is not desired.  In order to compensate for this limitation, each DTLS handshake message may be fragmented over <del> several DTLS records, each of which is intended to fit in a single IP packet.  Each DTLS handshake message contains both a fragment offset and a fragment length.  Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented </del>  message. 3.4. Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun.  In general, <del> implementations SHOULD discard packets from earlier epochs, but if </del>  packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that new epoch to be received prior to the completion of a handshake.  For instance, the server may send its Finished message and then start transmitting data.  Implementations MAY either buffer or discard such <del> packets, though when DTLS is used over reliable transports (e.g., </del>  SCTP RFC4960), they SHOULD be buffered and processed once the <del> handshake completes.  Note that TLS's restrictions on when packets may be sent still apply, and the receiver treats the packets as if </del>  they were sent in the right order. Implementations MUST send retransmissions of lost messages using the the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. <del> The received packet counter for a session MUST be initialized to zero </del>  when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after <del> deprotecting the packet; otherwise the packet discard might itself </del>  serve as a timing channel for the record number.  Note that decompressing the records number is still a potential timing channel for the record number, though a less powerful one than whether it was The "right" edge of the window represents the highest validated sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are <del> rejected.  Packets falling within the window are checked against a list of received packets within the window.  An efficient means for </del>  performing this check, based on the use of a bit mask, is described in Section 3.4.3 of RFC4303.  If the received record falls within the <del> window and is new, or if the packet is to the right of the window, then the packet is new. </del>  <del> The window MUST NOT be updated until the packet has been deprotected </del>  successfully. 4.5.2. of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. <del> Each range MUST be delivered in a single packet. </del>  When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.  DTLS Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message.  Implementations MUST either <del> discard or buffer all application data packets for the new epoch </del>  until they have received the Finished message for that epoch. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as ClientHellos. Note: it is not always possible to distinguish which association a <del> given packet is from.  For instance, if the client performs a </del>  handshake, abandons the connection, and then immediately starts a new handshake, it may not be possible to tell which connection a given protected record is for.  In these cases, trial decryption MAY be this requires implementations to track which messages appear in which records.  Once all the messages in a flight have been acknowledged, the implementation MUST cancel all retransmissions of that flight. <del> As noted above, the receipt of any packet responding to a given </del>  flight MUST be taken as an implicit acknowledgement for the entire flight. If implementations process out-of-epoch records as recommended in key-updates, then this creates a denial of service risk since an <del> adversary could inject packets with fake epoch values, forcing the </del>  recipient to compute the next-generation application_traffic_secret using the HKDF-Expand-Label construct to only find out that the message was does not pass the AEAD cipher processing.  The impact of

Reviewer comments:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.

Revised text:
datagrams are often limited to less than 1500 bytes if IP fragmentation is not desired.  In order to compensate for this limitation, each DTLS handshake message may be fragmented over  <ins> several DTLS records, each of which is intended to fit in a single UDP datagram.  Each DTLS handshake message contains both a fragment offset and a fragment length.  Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented </ins> message. 3.4. Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun.  In general,  <ins> implementations SHOULD discard records from earlier epochs, but if </ins> packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that new epoch to be received prior to the completion of a handshake.  For instance, the server may send its Finished message and then start transmitting data.  Implementations MAY either buffer or discard such  <ins> records, though when DTLS is used over reliable transports (e.g., </ins> SCTP RFC4960), they SHOULD be buffered and processed once the  <ins> handshake completes.  Note that TLS's restrictions on when records may be sent still apply, and the receiver treats the records as if </ins> they were sent in the right order. Implementations MUST send retransmissions of lost messages using the the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303.  <ins> The received record counter for a session MUST be initialized to zero </ins> when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after  <ins> deprotecting the record; otherwise the record discard might itself </ins> serve as a timing channel for the record number.  Note that decompressing the records number is still a potential timing channel for the record number, though a less powerful one than whether it was The "right" edge of the window represents the highest validated sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are  <ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for </ins> performing this check, based on the use of a bit mask, is described in Section 3.4.3 of RFC4303.  If the received record falls within the  <ins> window and is new, or if the record is to the right of the window, then the record is new. </ins>  <ins> The window MUST NOT be updated until the record has been deprotected </ins> successfully. 4.5.2. of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length.  <ins> Each range MUST be delivered in a single UDP datagram. </ins> When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.  DTLS Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message.  Implementations MUST either  <ins> discard or buffer all application data records for the new epoch </ins> until they have received the Finished message for that epoch. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as ClientHellos. Note: it is not always possible to distinguish which association a  <ins> given record is from.  For instance, if the client performs a </ins> handshake, abandons the connection, and then immediately starts a new handshake, it may not be possible to tell which connection a given protected record is for.  In these cases, trial decryption MAY be this requires implementations to track which messages appear in which records.  Once all the messages in a flight have been acknowledged, the implementation MUST cancel all retransmissions of that flight.  <ins> As noted above, the receipt of any record responding to a given </ins> flight MUST be taken as an implicit acknowledgement for the entire flight. If implementations process out-of-epoch records as recommended in key-updates, then this creates a denial of service risk since an  <ins> adversary could inject records with fake epoch values, forcing the </ins> recipient to compute the next-generation application_traffic_secret using the HKDF-Expand-Label construct to only find out that the message was does not pass the AEAD cipher processing.  The impact of