Original text:
Abstract <del> This document provides an overview of the architecture of Transport Services, a model for exposing transport protocol features to applications for network communication.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines the common set of terminology and concepts to be used in definitions of Transport Services APIs and implementations. </del>  1. One of the key insights to come from identifying the minimal set of features provided by transport protocols I-D.ietf-taps-minset was that features either require application interaction and guidance <del> (referred to as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols.  For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent. However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. </del>  1.2. It is important to note that neither the Transport Services API I- D.ietf-taps-interface nor the Implementation document I-D.ietf-taps- impl define new protocols or protocol capabilities that affect what <del> is communicated across the network.  The Transport Services system MUST be deployable on one side only.  A Transport Services system acting as a connection initiator can communicate with any existing system that implements the transport protocol(s) selected by the Transport Services system.  Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system, from existing initiators. </del>  4. Remote Endpoint: The Remote Endpoint represents the application's identifier for a peer that can participate in a transport <del> connection.  For example, the combination of a DNS name for the </del>  peer and a service name/port. Local Endpoint: The Local Endpoint represents the application's <del> identifier for itself that it uses for transport connections.  For </del>  example, a local IP address and port. Selection Properties: The Selection Properties consist of the Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection <del> behavior of the Transport System.  For example, a protocol- specific Connection Property can express that if UDP is used, the </del>  implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine spans of bytes, those spans of bytes are considered independent Messages.  Boundaries of a Message might or might not be understood or transmitted by transport protocols.  Specifically, <del> what one application considers to be two Messages sent on a </del>  stream-based transport can be treated as a single Message by the <del> application on the other side. </del>  Message Properties: Message Properties can be used to annotate specific Messages.  These properties might only apply to how

Reviewer comments:
Note that Security Considerations and Acknowledgments changes are newline-rewrap only.

Revised text:
Abstract  <ins> This document proposal an architecture for exposing transport protocol features to applications for network communication, the Transport Services architecture.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines common terminology and concepts to be used in definitions of Transport Services APIs and implementations. </ins> 1. One of the key insights to come from identifying the minimal set of features provided by transport protocols I-D.ietf-taps-minset was that features either require application interaction and guidance  <ins> (referred to in that document as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols. For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent.  However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. </ins> 1.2. It is important to note that neither the Transport Services API I- D.ietf-taps-interface nor the Implementation document I-D.ietf-taps- impl define new protocols or protocol capabilities that affect what  <ins> is communicated across the network: this implies that a Transport Services system MUST be deployable on only one side of a connection. A Transport Services system acting as a connection initiator can communicate with any existing system that implements the transport protocol(s) selected by the Transport Services system.  Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system, from existing initiators. </ins> 4. Remote Endpoint: The Remote Endpoint represents the application's identifier for a peer that can participate in a transport  <ins> connection; for example, the combination of a DNS name for the </ins> peer and a service name/port. Local Endpoint: The Local Endpoint represents the application's  <ins> identifier for itself that it uses for transport connections; for </ins> example, a local IP address and port. Selection Properties: The Selection Properties consist of the Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection  <ins> behavior of the Transport System; for example, a protocol-specific Connection Property can express that if UDP is used, the </ins> implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine spans of bytes, those spans of bytes are considered independent Messages.  Boundaries of a Message might or might not be understood or transmitted by transport protocols.  Specifically,  <ins> what one application considers to be multiple Messages sent on a </ins> stream-based transport can be treated as a single Message by the  <ins> application on the other side, and vice versa. </ins> Message Properties: Message Properties can be used to annotate specific Messages.  These properties might only apply to how