Original text:
5.5.  DTLS messages are grouped into a series of message flights, according to the diagrams below. Note: The application data sent by the client is not included in the timeout and retransmission calculation. <del> 5.6. </del>  <del> 5.6.1. </del>  DTLS uses a simple timeout and retransmission scheme with the state machine shown in dtls-timeout-state-machine.  Because DTLS clients evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer. <del> 5.6.2. </del>  Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems; for example, if timer to the initial value.  One situation where this might occur is when a rehandshake is used after substantial data transfer. <del> 5.7. </del>  CertificateVerify and Finished messages have the same format as in TLS 1.3.  Hash calculations include entire handshake messages, been sent as a single fragment following the algorithm described in Section 4.4.3 and Section 4.4.4 of TLS13, respectively. <del> 5.8. </del>  Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. <del> 5.9. </del>  If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is

Reviewer comments:
NAME
s'OK wi' me. The other thing to consider mentioning is that record shadowing (key compromise at epoch N allowing the attacker to send records that cause records at epoch >N to be dropped) isn't a concern because dropping records in DTLS is trivial.
NAME thoughts?

Revised text:
5.5. <ins> The DTLS 1.3 handshake has one important difference from the TLS 1.3 handshake: the EndOfEarlyData message is omitted both from the wire and the handshake transcript: because DTLS records have epochs, EndOfEarlyData is not necessary to determine when the early data is complete, and because DTLS is lossy, attackers can trivially mount the deletion attacks that EndOfEarlyData prevents in TLS.  Servers SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 1 record and SHOULD NOT accept epoch 1 data after the first epoch 3 record is received. 5.6. </ins> DTLS messages are grouped into a series of message flights, according to the diagrams below. Note: The application data sent by the client is not included in the timeout and retransmission calculation.  <ins> 5.7. </ins>  <ins> 5.7.1. </ins> DTLS uses a simple timeout and retransmission scheme with the state machine shown in dtls-timeout-state-machine.  Because DTLS clients evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer.  <ins> 5.7.2. </ins> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems; for example, if timer to the initial value.  One situation where this might occur is when a rehandshake is used after substantial data transfer.  <ins> 5.8. </ins> CertificateVerify and Finished messages have the same format as in TLS 1.3.  Hash calculations include entire handshake messages, been sent as a single fragment following the algorithm described in Section 4.4.3 and Section 4.4.4 of TLS13, respectively.  <ins> 5.9. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected.  <ins> 5.10. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is