Draft: draft-ietf-taps-interface

Commentary: I read the API draft and fixed a couple of minor issues . That is , they 're minor as far as I can see - please tell me if you disagree . 
 Lots of good finds , I was surprised to see how many I must have overlooked when I last read this ! Thanks for doing this!Go ahead – Thank you for the fixes .
Paragraph (version A):
Internally, the transport system will first exclude all protocols and
paths that match a Prohibit, then exclude all protocols and paths
that do not match a Require, then sort candidates according to
Preferred properties, and then use Avoided properties as a
tiebreaker.  Selection Properties that select paths take preference
over those that select protocols.  For example, if an application
indicates a preference for a specific path by specifying an
interface, but also a preference for a protocol not available on this
path, the transport system will try the path first, ignoring the
preference.
Paragraph (version B):
Internally, the transport system will first exclude all protocols and
paths that match a Prohibit, then exclude all protocols and paths
that do not match a Require, then sort candidates according to
Preferred properties, and then use Avoided properties as a
tiebreaker.  Selection Properties that select paths take preference
over those that select protocols.  For example, if an application
indicates a preference for a specific path by specifying an
interface, but also a preference for a protocol not available on this
path, the transport system will try the path first, ignoring the
protocol preference.
Paragraph (version A):
Prefer the use of stable local addresses for Listeners and
Rendezvous Connections, and prefer the use of temporary addresses
for other Connections.
Paragraph (version B):
The default is to prefer the use of stable local addresses for
Listeners and Rendezvous Connections, and to prefer the use of
temporary addresses for other Connections.
Paragraph (version A):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors.  Note that even if a protocol
supporting this property is selected, not all ICMP errors will
necessarily be delivered, so applications cannot rely on receiving
them.  The default is to Ignore this option.
Paragraph (version B):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors, see soft-errors.  Note that even if
a protocol supporting this property is selected, not all ICMP errors
will necessarily be delivered, so applications cannot rely on
receiving them.  The default is to Ignore this option.
Paragraph (version A):
Message Properties may be inconsistent with the properties of the
Protocol Stacks underlying the Connection on which a given Message is
sent.  For example, a Connection must provide reliability to allow
setting an infinitie value for the lifetime property of a Message.
Sending a Message with Message Properties inconsistent with the
Selection Properties of the Connection yields an error.
Paragraph (version B):
Message Properties may be inconsistent with the properties of the
Protocol Stacks underlying the Connection on which a given Message is
sent.  For example, a Connection must provide reliability to allow
setting an infinite value for the lifetime property of a Message.
Sending a Message with Message Properties inconsistent with the
Selection Properties of the Connection yields an error.
Paragraph (version A):
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 B):
If true, it specifies that the receiver-side transport protocol stack
may 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):
When true, 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 for Connections that
were established with the Selection Property 'Reliable Data Transfer
(Connection)' enabled.  When this is not the case, changing it will
generate an error.  Disabling this property indicates that the
transport system may disable retransmissions or other reliability
mechanisms for this particular Message, but such disabling is not
guaranteed.
Paragraph (version B):
When true, 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 for Connections that
were established with the Selection Property 'Configure Per-Message
Reliability' enabled.  When this is not the case, changing it will
generate an error.  Disabling this property indicates that the
transport system may disable retransmissions or other reliability
mechanisms for this particular Message, but such disabling is not
guaranteed.
Paragraph (version A):
As with sending, the type of the Message to be passed is dependent on
the implementation, and on the constraints on the Protocol Stacks
implied by the Connection's transport parameters.
Paragraph (version B):
As with sending, the type of the Message to be passed is dependent on
the implementation, and on the constraints on the Protocol Stacks
implied by the Connection's Transport Properties.
Paragraph (version A):
Note that maxLength does not guarantee that the application will
receive that many bytes if they are available; the interface may
return ReceivedPartial events with less data than maxLength according
to implementation constraints.  Note also that maxLength and
minIncompleteLength are intended only to manage buffering, and are
not interpreted as a reciever preference for message reordering.
Paragraph (version B):
Note that maxLength does not guarantee that the application will
receive that many bytes if they are available; the interface may
return ReceivedPartial events with less data than maxLength according
to implementation constraints.  Note also that maxLength and
minIncompleteLength are intended only to manage buffering, and are
not interpreted as a receiver preference for message reordering.
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.  Such
conditions that irrevocably lead to the termination of the Connection
are signaled using ConnectionError instead (see termination).
Paragraph (version B):
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 signaled using ConnectionError instead (see termination).
Paragraph (version A):
The Message Context can indicate whether or not this Message is the
Final Message on a Connection.  For any Message that is marked as
Final, the application can assume that there will be no more Messages
received on the Connection once the Message has been completely
delivered.  This corresponds to the Final property that may be marked
on a sent Message msg-final.
Paragraph (version B):
The Message Context can indicate whether or not this Message is the
Final Message on a Connection.  For any Message that is marked as
Final, the application can assume that there will be no more Messages
received on the Connection once the Message has been completely
delivered.  This corresponds to the Final property that may be marked
on a sent Message, see msg-final.
Paragraph (version A):
Using the MessageContext object, the application can set and retrieve
meta-data of the message, including Message Properties (see message-
props) and framing meta-data (see framing-meta).  Therefore, a
MessageContext object can be passed to the Send action and is retuned
by each Send and Receive related events.
Paragraph (version B):
Using the MessageContext object, the application can set and retrieve
meta-data of the message, including Message Properties (see message-
props) and framing meta-data (see framing-meta).  Therefore, a
MessageContext object can be passed to the Send action and is
returned by each Send and Receive related event.
Paragraph (version A):
The application prefers loss to latency but is not interactive.
Response time should be optimized at the expense of bandwidth
efficiency and delay variation when sending on this
connection.Transport system implementations that map the requested
capacity profile onto per-connection DSCP signaling without
multiplexing SHOULD assign a DSCP Assured Forwarding
(AF21,AF22,AF23,AF24) RFC2597 PHB; when the Connection is
multiplexed, the guidelines in Section 6 of RFC7657 apply.
Paragraph (version B):
The application prefers loss to latency but is not interactive.
Response time should be optimized at the expense of bandwidth
efficiency and delay variation when sending on this connection.
Transport system implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing
SHOULD assign a DSCP Assured Forwarding (AF21,AF22,AF23,AF24)
RFC2597 PHB; when the Connection is multiplexed, the guidelines in
Section 6 of RFC7657 apply.