Change:
In response to feedback on the mailing list (URL), this PR attempts to clarify (a) when to generate ACKs, and (b) which records to ACK.
This is much clearer to me. I see that you have removed the sentence I was having a problem with in the bullet: "Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted"; logically, I believe you have captured this better by adding "and processed" above in "The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side."
NAME Thank you for your feedback! I have removed the sentence because its content is already implied by what's stated in the previous section . See the commit description of URL
NAME thanks. This sensibly improves readability and clarity. Hi Hanno, Thank you for your clarifications. The example you gave helps a lot. I believe I now understand the text as written in this bullet (first bullet, not second--my bad). I no longer think it needs re-wording. Best regards, Jonathan Hanno Becker wrote:

Discussion:
7. <del> The ACK message is used by an endpoint to indicate handshake- containing the TLS records it has received from the other side.  ACK is not a handshake message but is rather a separate content type, with code point TBD (proposed, 25).  This avoids having ACK being added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. </del> <ins> The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side.  ACK is not a handshake message but is rather a separate content type, with code point TBD (proposed, 25).  This avoids having ACK being added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. </ins> %%% ACKs struct { RecordNumber record_numbers<0..2^16-1>; } ACK;

flight which the endpoint has received and either processed or buffered, in numerically increasing order. <del> Implementations MUST NOT acknowledge records containing non- duplicative handshake messages or fragments which have not been processed or buffered.  Otherwise, deadlock can ensue. </del> <ins> Implementations MUST NOT acknowledge records containing handshake messages or fragments which have not been processed or buffered. Otherwise, deadlock can ensue.  As an example, implementations MUST NOT send ACKs for handshake messages which they discard as out-of- order. </ins> During the handshake, ACKs only cover the current outstanding flight (this is possible because DTLS is generally a lockstep protocol).

7.1. <del> When an implementation receives a partial flight, it SHOULD generate an ACK that covers the messages from that flight which it has received so far.  Implementations have some discretion about when to generate ACKs, but it is RECOMMENDED that they do so under two circumstances: </del> <ins> When an implementation detects a disruption in the receipt of the current incoming flight, it SHOULD generate an ACK that covers the messages from that flight which it has received and processed so far. Implementations have some discretion about which events to treat as signs of disruption, but it is RECOMMENDED that they generate ACKs under two circumstances: </ins> When they receive a message or fragment which is out of order, either because it is not the next expected message or because it <del> is not the next piece of the current message.  Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted. </del> <ins> is not the next piece of the current message. </ins> When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP