Change:
Based on discussion with NAME rearrange things to put a proper document overview in the intro, and split out the API Model discussion into its own section outside of the introduction.
LGTM (modulo one nit)Thank you NAME to do this - really improves the structure.

Discussion:
1.1. <ins> The Transport Services architecture is based on the survey of Services Provided by IETF Transport Protocols and Congestion Control Mechanisms RFC8095, and the distilled minimal set of the features offered by transport protocols I-D.ietf-taps-minset.  These documents identified common features and patterns across all transport protocols developed thus far in the IETF. Since transport security is an increasingly relevant aspect of using transport protocols on the Internet, this architecture also considers the impact of transport security protocols on the feature-set exposed by transport services I-D.ietf-taps-transport-security. 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 (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. 1.2. This document describes the Transport Services architecture in three sections: model describes how the API model of Transport Services differs from traditional socket-based APIs.  Specifically, it offers asynchronous event-driven interaction, the use of messages for data transfer, and the ability to easily adopt different transport protocols. design explains the design principles that guide the Transport Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without requiring too many changes by application developers. concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and implementation documents.  The Preconnection allows applications to configure connection properties, and the Connection represents an object that can be used to send and receive Messages. 1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. 2. </ins> The traditional model of using sockets for networking can be represented as follows:

can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams. <del> 1.2. </del> <ins> 2.1. </ins> Originally, sockets presented a blocking interface for establishing connections and transferring data.  However, most modern applications

opposed to how sockets represent network resources as file system objects that may be temporarily unavailable. <del> 1.3. </del> <ins> 2.2. </ins> Sockets provide a message interface for datagram protocols like UDP, but provide an unstructured stream abstraction for TCP.  While TCP

transport services, while simplifying the application's role in parsing data. <del> 1.4. </del> <ins> 2.3. </ins> Sockets, for protocols like TCP, are generally limited to connecting to a single address over a single interface.  They also present a

support initiating and receiving new streams using existing connections. <del> 2. The Transport Services architecture is based on the survey of Services Provided by IETF Transport Protocols and Congestion Control Mechanisms RFC8095, and the distilled minimal set of the features offered by transport protocols I-D.ietf-taps-minset.  These documents identified common features and patterns across all transport protocols developed thus far in the IETF. Since transport security is an increasingly relevant aspect of using transport protocols on the Internet, this architecture also considers the impact of transport security protocols on the feature-set exposed by transport services I-D.ietf-taps-transport-security. 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 (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. 2.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. The goal of the Transport Services architecture is to redefine the