Draft: draft-ietf-taps-interface

Commentary: Tries to clarify that a Connection is a logical connection , and does n't necessarily require a connection oriented underlying transport protocol . Cross - reference to the descriptions of Preconnection and the connection establishment procedures . 
 Interface , Section 2 , " A unified interface to datagram and connection - oriented transports , allowing use of a common API for connection - establishment and closing " . Should this be " … to datagram and stream - oriented transports " ? At what point do we explain that and are also used for connectionless protocols ? This change would finesse the question here , leaving it for Section 3 , or we can restructure the draft to clarify earlier . 
 Yes to ( 1 ): Datagram protocols can be connection - oriented or not ; however the point here seems to be either : /interface to datagram and stream - oriented transports/ or /interface to both connection - less and connection - oriented transports/ ... I 'd favour the first , it 's clear enough and does n't use terms that we later re - use . Also to ( 2 ): I think we could insert a specific sentence after : " A Connection represents an instance of a transport   on which data can be sent to and/or received from a Remote Endpoint ( i.e. , depending on the kind of transport , connections can be bi - directional or unidirectional ) . " That explicitly says something like : " This connections are presently consistently to the application , irrespective of whether the underlying transport is connection - less and connection - oriented . " 
 Looks good . Can we also change to something like this in section 1 : /A unified interface to datagram and connection - oriented transport protocols , allowing use of a common API for connection - establishment and closing;/
Paragraph (version A):
An application primarily interacts with this API through two Objects:
Preconnections and Connections.  A Preconnection represents a set of
properties and constraints on the selection and configuration of
paths and protocols to establish a Connection with an Endpoint.  A
Connection represents an instance of a transport Protocol Stack on
which data can be sent to and/or received from a Remote Endpoint
(i.e., depending on the kind of transport, connections can be bi-
directional or unidirectional).  Connections can be created from
Preconnections in three ways: by initiating the Preconnection (i.e.,
actively opening, as in a client), through listening on the
Preconnection (i.e., passively opening, as in a server), or
rendezvousing on the Preconnection (i.e.  peer to peer
establishment).
Paragraph (version B):
An application primarily interacts with this API through two Objects:
Preconnections and Connections.  A Preconnection object (pre-
establishment) represents a set of properties and constraints on the
selection and configuration of paths and protocols to establish a
Connection with an Endpoint.  A Connection object represents an
instance of a transport Protocol Stack on which data can be sent to
and/or received from a Remote Endpoint (i.e., a logical connection
that, depending on the kind of transport, can be bi-directional or
unidirectional, and that can use a stream protocol or a datagram
protocol).  Connections can be created from Preconnections in three
ways: by initiating the Preconnection (i.e., actively opening, as in
a client; initiate), through listening on the Preconnection (i.e.,
passively opening, as in a server listen), or rendezvousing on the
Preconnection (i.e.  peer to peer establishment; rendezvous).