Original text:
7.3.2.3. A ReceiveError occurs when data is received by the underlying <del> Protocol Stack that cannot be fully retrieved or parsed, or when some other indication is received that reception has failed.  In contrast, conditions that irrevocably lead to the termination of the Connection are instead signaled using ConnectionError (see termination). The ReceiveError event passes an optional associated MessageContext. This can indicate that a Message that was being partially received previously, but had not completed, encountered an error and will not be completed. </del>  7.3.3.

Reviewer comments:
Actually handling of receive error is also not fully clear to me. Section 7.3.2.3 says: "A ReceiveError occurs when data is received by the underlying Protocol Stack that cannot be fully retrieved or parsed" However, I assume that this error should rather not be called if a transport is reliable because the assumption is that the packet will be retransmitted, right? E.g. in case of QUIC if a packet cannot be decrypted would that trigger an error or not? I assume not, because the QUIC stack cannot even know if a packet contained any payload data, right?
I agree that this is not very clear - to me, the cases that you describe are cases that should not throw this error, because it's a problem of the underlying protocol and not relevant to the application (what's an application going to do with it anyway?). I can only see two relevant cases of errors: the one example that we already give: "a Message that was being partially received previously, but had not completed, encountered an error and will not be completed." - note that this does not assume a fully reliable transfer, because in this case, the underlying stack would solve it, and the fact that there are retransmissions shouldn't be relevant to the application. So this means "you got a partial message from me before, but now I can tell you that you won't get the rest". the case discussed in : a minimum checksum coverage range was required for reception, but this promise was not kept => the Transport Services system will have to be discard the incoming message. There may well be others, but it's probably good to give these two examples, not only one, to make it clearer what kinds of errors are covered by this, and to explicitly state that this is only about errors that are relevant to the application, not protocol-internal reception errors.
I think this is how I see it. These errors should be actionable by the upper layer, in contrast something that fails an auth check is not actionable by an upper layer protocol. A different other use is for logging ... to diagnose fault, where you could want to see what isn’t processed by the lower layers. This is not the use I see here. Gorry
Mich clearer, but need more refinement.

Revised text:
7.3.2.3. A ReceiveError occurs when data is received by the underlying  <ins> Protocol Stack that cannot be fully retrieved or parsed, and when it is useful for the application to be notified of such errors.  For example, a ReceiveError can indicate that a Message (identified via the MessageContext) that was being partially received previously, but had not completed, encountered an error and will not be completed. This can be useful for an application, which may want to use this error as a hint to remove previously received Message parts from memory.  As another example, if an incoming Message does not fulfill the Required Minimum Corruption Protection Coverage for Receiving property (see conn-recv-checksum), an application can use this error as a hint to inform the peer application to adjust the Sending Corruption Protection Length property (see msg-checksum). In contrast, internal protocol reception errors (e.g., loss causing retransmissions in TCP) are not signalled by this Event.  Conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError (see termination). </ins> 7.3.3.