Draft: draft-ietf-taps-interface

Commentary: I did n't like something about reliability ( let 's not throw an error when we ca n't be UNreliable , only when we ca n't be reliable ) . I updated the text on ordering a bit , to say that the Property is ignored for the first Message on a Connection , and rephrased it slightly to talk about the receiver - side transport system and the receiving application - before , the text might have talked about a sender - side behavior . I a TODO DISCUSS comment about per - message Niceness . 
 Fine with me , maybe fix minor knitThanks , all good now I think .
Paragraph (version A):
If true, it specifies that a Message should be delivered to the other
side after the previous Message which was passed to the same
Connection via the Send Action.  If false, the Message may be
delivered out of order.  This property is used for protocols that
support preservation of data ordering, see prop-ordering, but allow
out-of-order delivery for certain messages.
Paragraph (version B):
If true, it specifies that the receiver-side transport protocol stack
only deliver the Message to the receiving application after the
previous ordered Message which was passed to the same Connection via
the Send Action, when such a Message exists.  If false, the Message
may be delivered to the receiving application out of order.  This
property is used for protocols that support preservation of data
ordering, see prop-ordering, but allow out-of-order delivery for
certain messages.
Paragraph (version A):
This property specifies that a message should be sent in such a way
that the transport protocol ensures all data is received on the other
side without corruption.  Changing the 'Reliable Data Transfer'
property on Messages is only possible if the transport protocol
supports partial reliability (see prop-partially-reliable).
Therefore, for protocols that always transfer data reliably, this
property is always true and for protocols that always transfer data
unreliably, this property is always false.  Changing it may generate
an error.
Paragraph (version B):
This property specifies that a message should be sent in such a way
that the transport protocol ensures all data is received on the other
side without corruption.  Changing the 'Reliable Data Transfer'
property on Messages is only possible if the Connection supports
reliability.  When this is not the case, changing it will generate an
error.
Paragraph (version A):
This property specifies whether the application wishes to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.  The default is to enable Reliable
Data Transfer.
Paragraph (version B):
This property specifies whether the application needs to use a
transport protocol that ensures that all data is received on the
other side without corruption.  This also entails being notified when
a Connection is closed or aborted.  The default is to enable Reliable
Data Transfer.
Paragraph (version A):
Note that this property is not a per-message override of the
connection Niceness - see conn-niceness.  Both Niceness properties
may interact, but can be used indepentendly and be realized by
different mechanisms.
Paragraph (version B):
Note that this property is not a per-message override of the
connection Niceness - see conn-niceness.  Both Niceness properties
may interact, but can be used independently and be realized by
different mechanisms.