Draft: draft-ietf-taps-interface

Commentary: 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 can not 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 can not be decrypted would that trigger an error or not ? I assume not , because the QUIC stack can not 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 : 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 should n'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 wo n't get the rest " . 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 is n’t processed by the lower layers . This is not the use I see here .    clearer , but need more refinement .
Paragraph (version A):
A ReceiveError occurs when data is received by the underlying
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).
Paragraph (version A):
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.
Paragraph (version B):
A ReceiveError occurs when data is received by the underlying
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).
Paragraph (version B):
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).