Draft: draft-ietf-taps-interface

Commentary: Feel free to cherry - pick . Some of these are self - explanatory ; in other cases , I 'll add a comment to explain the change . 
 Thanks a lot for doing this , several great catches there ! I made a few minor suggestions
Paragraph (version B):
Explicit support for transport-specific features to be applied
should that particular transport be part of a chosen Protocol
Stack.
Paragraph (version A):
If none of the available transport protocols provides Preservation of
Message Boundaries, but there is a transport protocol that provides a
reliable ordered byte stream, an application could receive this byte
stream as partial Messages and transform it into application-layer
Messages.  Alternatively, an application might provide a Message
Framer, which can transform a byte stream into a sequence of Messages
(framing).
Paragraph (version B):
If none of the available transport protocols provides Preservation of
Message Boundaries, but there is a transport protocol that provides a
reliable ordered byte stream, an application could receive this byte
stream as partial Messages and transform it into application-layer
Messages.  Alternatively, an application might provide a Message
Framer, which can transform a sequence of Messages into a byte stream
and vice versa (framing).
Paragraph (version A):
Implementations of this interface SHOULD implement each Selection
Property, Connection Property, and Message Context Property
specified in this document.  Each interface SHOULD be implemented
even when in a specific implementation/platform it will always
result in no operation, e.g. there is no action when the API
specifies a Property that is not available in a transport protocol
implemented on a specific platform.  For example, if TCP is the
only underlying transport protocol, the Message Property
"msgOrdered" can be implemented even if disabling ordering will
not have any effect TCP because the API does not guarantee out-of-
order delivery.  Similarly, the "msg-lifetime" Message Property
can be implemented but ignored, as the description of this
Property states that "it is not guaranteed that a Message will not
be sent when its Lifetime has expired".
Paragraph (version B):
Implementations of this interface SHOULD implement each Selection
Property, Connection Property, and Message Context Property
specified in this document.  Each interface SHOULD be implemented
even when in a specific implementation/platform it will always
result in no operation, e.g. there is no action when the API
specifies a Property that is not available in a transport protocol
implemented on a specific platform.  For example, if TCP is the
only underlying transport protocol, the Message Property
"msgOrdered" can be implemented (trivially, as a no-op) as
disabling the requirement for ordering will not have any effect on
delivery order for Connections over TCP.  Similarly, the "msg-
lifetime" Message Property can be implemented but ignored, as the
description of this Property states that "it is not guaranteed
that a Message will not be sent when its Lifetime has expired".
Paragraph (version A):
The Local Endpoint MUST be specified if the Preconnection is used to
Listen() for incoming Connections, but is OPTIONAL if it is used to
Initiate() connections.  If no Local Endpoint is specified, the
Transport System will assign an ephemeral local port to the
Connection.  The Remote Endpoint MUST be specified if the
Preconnection is used to Initiate() Connections, but is OPTIONAL if
it is used to Listen() for incoming Connections.  The Local Endpoint
and the Remote Endpoint MUST both be specified if a peer-to-peer
Rendezvous is to occur based on the Preconnection.
Paragraph (version B):
The Local Endpoint MUST be specified if the Preconnection is used to
Listen() for incoming Connections, but is OPTIONAL if it is used to
Initiate() connections.  If no Local Endpoint is specified, the
Transport System will assign an ephemeral local port to the
Connection on the appropriate interface(s).  The Remote Endpoint MUST
be specified if the Preconnection is used to Initiate() Connections,
but is OPTIONAL if it is used to Listen() for incoming Connections.
The Local Endpoint and the Remote Endpoint MUST both be specified if
a peer-to-peer Rendezvous is to occur based on the Preconnection.
Paragraph (version A):
In addition, the pseudo-level "Default" can be used to reset the
property to the default level used by the implementation.  This level
will never show up when queuing the value of a preference - the
effective preference must be returned instead.
Paragraph (version B):
In addition, the pseudo-level "Default" can be used to reset the
property to the default level used by the implementation.  This level
will never show up when querying the value of a preference: the
effective preference must be returned instead.
Paragraph (version A):
This property specifies whether the application would like the
Connection to be congestion controlled or not.  Note that if a
Connection is not congestion controlled, an application using such a
Connection SHOULD itself perform congestion control in accordance
with RFC8085, RFC2914, RFC2119.  Also note that reliability is
usually combined with congestion control in protocol implementations,
rendering "reliable but not congestion controlled" a request that is
unlikely to succeed.  If the Connection is congestion controlled,
performing additional congestion control in the application can have
negative performance implications.
Paragraph (version B):
This property specifies whether the application would like the
Connection to be congestion controlled or not.  Note that if a
Connection is not congestion controlled, an application using such a
Connection SHOULD itself perform congestion control in accordance
with RFC2914 or use a circuit breaker in accordance with RFC8084,
whichever is appropriate.  Also note that reliability is usually
combined with congestion control in protocol implementations,
rendering "reliable but not congestion controlled" a request that is
unlikely to succeed.  If the Connection is congestion controlled,
performing additional congestion control in the application can have
negative performance implications.
Paragraph (version A):
The set of valid interface types is implementation- and system-
specific.  For example, on a mobile device, there may be "Wi-Fi" and
"Cellular" interface types available; whereas on a desktop computer,
"Wi-Fi" and "Wired Ethernet" interface types might be available.  An
implementation should provide all types that are supported on the
local system to all remote systems, to allow applications to be
written generically.  For example, if a single implementation is used
on both mobile devices and desktop devices, it should define the
"Cellular" interface type for both systems, since an application
might wish to always "Prohibit Cellular".
Paragraph (version B):
The set of valid interface types is implementation- and system-
specific.  For example, on a mobile device, there may be "Wi-Fi" and
"Cellular" interface types available; whereas on a desktop computer,
"Wi-Fi" and "Wired Ethernet" interface types might be available.  An
implementation should provide all types that are supported on the
local system to all remote systems, to allow applications to be
written generically.  For example, if a single implementation is used
on both mobile devices and desktop devices, it should define the
"Cellular" interface type for both systems, since an application
might wish to always prohibit cellular.
Paragraph (version A):
Session cache management: Used to tune cache capacity, lifetime,
re-use, and eviction policies, e.g., LRU or FIFO.may also me
changed, but are implementation-specific.
Paragraph (version B):
Session cache management: Used to tune cache capacity, lifetime,
re-use, and eviction policies, e.g., LRU or FIFO.
Paragraph (version A):
When sending Messages, applications can add specific Message values
to a MessageContext (msg-ctx) that is intended for a Framer.  This
can be used, for example, to set the type of a Message for a TLV
format.  The namespace of values is custom for each unique Message
Framer.
Paragraph (version B):
When sending Messages, applications can add Framer-specific key/value
pairs to a MessageContext (msg-ctx).  This mechanism can be used, for
example, to set the type of a Message for a TLV format.  The
namespace of values is custom for each unique Message Framer.
Paragraph (version A):
Applications can need to annotate the Messages they send with extra
information to control how data is scheduled and processed by the
transport protocols in the Connection.  Therefore a message context
containing these properties can be passed to the Send Action.  For
other uses of the message context, see msg-ctx.
Paragraph (version B):
Applications needing to annotate the Messages they send with extra
information (for example, to control how data is scheduled and
processed by the transport protocols supporting the Connection) can
include this information in the Message Context passed to the Send
Action.  For other uses of the message context, see msg-ctx.