Draft: draft-ietf-taps-impl

Commentary: So implementation talks about pooled connections - I must have blinked and missed that , obviously it is different to a connection group - or is it ? If I am asking a silly question then I suspect we need just a few lines of text to demuddle me . 
 LGTM , thanks !
Paragraph (version A):
A request by an application for Protocol Properties that include
requirements or prohibitions that cannot be satisfied by any of
the available protocols.  For example, if an application requires
"Configure Reliability per Message", but no such feature is
available in any protocol the host running the transport system on
the host running the transport system this should result in an
error, e.g., when SCTP is not supported by the operating system.
Paragraph (version B):
A request by an application for Protocol Properties that cannot be
satisfied by any of the available protocols.  For example, if an
application requires "Configure Reliability per Message", but no
such feature is available in any protocol the host running the
transport system on the host running the transport system this
should result in an error, e.g., when SCTP is not supported by the
operating system.
Paragraph (version A):
For protocols that employ request/response pairs and do not require
in-order delivery of the responses, like HTTP, the transport
implementation may distribute interactions across several underlying
transport connections.  For these kinds of protocols, implementations
may hide the connection management and only expose a single
Connection object and the individual requests/responses as messages.
These Pooled Connections can use multiple connections or multiple
streams of multi-streaming connections between endpoints, as long as
all of these satisfy the requirements, and prohibitions specified in
the Selection Properties of the Pooled Connection.  This enables
implementations to realize transparent connection coalescing,
connection migration, and to perform per-message endpoint and path
selection by choosing among these underlying connections.
Paragraph (version B):
For applications that do not need in-order delivery of Messages, the
Transport Services implementation may distribute Messages of a single
Connection across several underlying transport connections or
multiple streams of multi-streaming connections between endpoints, as
long as all of these satisfy the Selection Properties.  The Transport
Services implementation will then hide this connection management and
only expose a single Connection object, which we here call a "Pooled
Connection".  This is in contrast to Connection Groups, which
explicitly expose combined treatment of Connections, giving the
application control over multiplexing, for example.
Paragraph (version B):
Pooled Connections can be useful when the application using the
Transport Services system implements a protocol such as HTTP, which
employs request/response pairs and does not require in-order delivery
of responses.  This enables implementations of Transport Services
systems to realize transparent connection coalescing, connection
migration, and to perform per-message endpoint and path selection by
choosing among multiple underlying connections.