Original text:
4. <del> [EDITOR'S NOTE: write three paragraph summary here; see https://github.com/taps-api/drafts/issues/93] </del>  In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of <del> a connection, following the phases described in TAPS-ARCH. </del>  5. Endpoint or a Remote Endpoint in cases where this is required, for example with some NAT traversal protocols (see rendezvous). <del> [NOTE: the API needs MUST be explicit about when name resolution occurs, since the act of resolving a name leaks information, and there may be security implications if this happens unexpectedly.] </del> 5.2. A Preconnection object holds parameters reflecting the application's connections.  This list can be passed to a peer via a signalling protocol, such as SIP or WebRTC, to configure the remote. <del> [NOTE: This API is sufficient for TCP-style simultaneous open, but should be considered experimental for ICE-like protocols.] </del> 6.4. Groups of Connections can be created using Clone action:

Reviewer comments:
There are still a few s and similar scattered throughout the document. Find them and fix them, or move them to post-London issues.

Revised text:
4.  <ins> The Transport Services Interface is the basic common abstract application programming interface to the Transport Services Architecture defined in TAPS-ARCH.  An application primarily interacts with this interface through two objects, Preconnections and Connections.  A Preconnection represents a set of parameters and constraints on the selection and configuration of paths and protocols to establish a connection with a remote endpoint.  A Connection represents a transport protocol stack on which data can be sent to and received from a remote endpoint.  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). Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message boundaries both via explicit protocol stack support, and via application support through a deframing callback which finds message boundaries in a stream.  Messages are received asynchronously through a callback registered by the application.  Error and other notifications also happen asynchronously on the Connection. </ins> In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of  <ins> a connection, following the phases described in TAPS-ARCH.  An example interface sketch in Go is shown in appendix-api-sketch. </ins> 5. Endpoint or a Remote Endpoint in cases where this is required, for example with some NAT traversal protocols (see rendezvous).  5.2. A Preconnection object holds parameters reflecting the application's connections.  This list can be passed to a peer via a signalling protocol, such as SIP or WebRTC, to configure the remote.  6.4. Groups of Connections can be created using Clone action: