Change:
in the TAPS Architecture I-D.ietf-taps-arch. An application primarily interacts with this API through two Objects: <del> 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). </del> <ins> 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). </ins> Once a Connection is established, data can be sent and received on it in the form of Messages.  The interface supports the preservation of

Discussion:
Tries to clarify that a Connection is a logical connection, and doesn'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 doesn'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 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). " 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;/