Original text:
1. <del> Many APIs to perform transport networking have been deployed, perhaps the most widely known and imitated being the BSD socket() POSIX interface.  The names and functions between these APIs are not consistent, and vary depending on the protocol being used.  For example, sending and receiving on a stream of data is conceptually the same between operating on an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13 stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of protocols offering transport services vary based on the context of the protocols themselves.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </del>  The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As multiple sets of protocols and protocol features, it can use these protocols across multiple paths that may have different performance and functional characteristics, and it can communicate with different <del> Remote Endpoints to optimize performance.  Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring changes in applications for adoption. </del>  The following considerations were used in the design of this architecture. 3.2. <del> Since applications will often need to control fine-grained details of transport protocols to optimize their behavior and ensure compatibility with remote peers, a Transport Services system also needs to allow more specialized protocol features to be used.  The interface for these specialized options should be exposed differently from the common options to ensure flexibility. </del>  <del> A specialized feature may be required by an application only when </del>  using a specific protocol, and not when using others.  For example, <del> if an application is using UDP, it may require control over the </del>  checksum or fragmentation behavior for UDP; if it used a protocol to frame its data over a byte stream like TCP, it would not need these options.  In such cases, the API should expose the features in such a way that they take effect when a particular protocol is selected, but <del> do not imply that only that protocol may be used if there are </del>  equivalent options. Other specialized features, however, may be strictly required by an possible that some very constrained devices might not have, for example, a full TCP implementation. <del> In order to preserve flexibility and compatibility with future protocols, top-level features in the Transport Services API should avoid referencing particular transport protocols.  Mappings of these API features in the Implementation document, on the other hand, must explain the ramifications of each feature on existing protocols.  It is expected that the Implementation document will be updated and supplemented as new protocols and protocol features are developed. </del>  It is important to note that neither the Transport Services API nor the Implementation document defines new protocols that require any <del> changes on remote hosts.  The Transport Services system must be </del>  deployable on one side only, as a way to allow an application to make better use of available capabilities on a system and protocol features that may be supported by peers across the network.

Reviewer comments:
From /Introudction/ Please define/API/ in /Many APIs to perform/. First Para mentions TCP, but not UDP - some people could draw conclusions (very silly perhaps) that this is about TCP. It would be super nice to include an e.g. with Datagrams mentioning QUIC and UDP. ... From /Design principles/ Curent text: /and it can communicate with different Remote Endpoints to optimize performance./ My new proposed text: /and it can communicate with different Remote Endpoints to optimize performance, robustness to failure, or some other metric/. From /Access to Specialized Features/ This says: /Since applications will often need to control fine-grained details of transport protocols to optimize their behavior and ensure compatibility with remote peers, a Transport Services system also needs to allow more specialized protocol features to be used./ I quibble. I don’t believe this is /often/, and anyway I do not think this is the most prevalent case, just and important usage, so I would suggest we write something: /There are applications that will need to control fine-grained details of transport protocols to optimize their behavior and ensure compatibility with remote peers,. A Transport Services system will therefore also needsto allow more specialized protocol features to be used./ From /Access to Specialized Features/ This says: /A specialized feature may be required by an application only when using a specific protocol, / I suggest: /A specialized feature could be required by an application only when it uses a specific transport protocol, / and change: /For example, if an application is using UDP, it may require/ to: /For example, if an application is using UDP, it could require/ Please remove /In order to preserve flexibility and compatibility .../ Suggest: /To preserve flexibility and compatibility .../ Please change: /Mappings of these API features in the Implementation document, on the other hand, must explain the ramifications of each feature on existing protocols. It is expected that the Implementation document will be updated and supplemented as new protocols and protocol features are developed./ to this: /The mappings of these API features is explained in the TAPS Implementation [REF], which also explain the implications of the feature provided by existing protocols. It is expected that this documentation will be updated and supplemented as new protocols and protocol features are developed./ Please change: /require any changes on remote hosts./ suggest: /require any changes to a remote host./ Please change: /Transport protocols such as SCTP provide/ add commas: /Transport protocols, such as SCTP, provide/
lgtm with one nit

Revised text:
1.  <ins> Many application programming interfaces (APIs) to perform transport networking have been deployed, perhaps the most widely known and imitated being the BSD socket() POSIX interface.  The names and functions between these APIs are not consistent, and vary depending on the protocol being used.  For example, sending and receiving on a stream of data is conceptually the same between operating on an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13 stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of protocols offering transport services vary based on the context of the protocols themselves.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </ins> The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As multiple sets of protocols and protocol features, it can use these protocols across multiple paths that may have different performance and functional characteristics, and it can communicate with different  <ins> Remote Endpoints to optimize performance, robustness to failure, or some other metric.  Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring changes in applications for adoption. </ins> The following considerations were used in the design of this architecture. 3.2.  <ins> There are applications that will need to control fine-grained details of transport protocols to optimize their behavior and ensure compatibility with remote peers,. A Transport Services system will therefore also needs to allow more specialized protocol features to be used.  The interface for these specialized options should be exposed differently from the common options to ensure flexibility. </ins>  <ins> A specialized feature could be required by an application only when </ins> using a specific protocol, and not when using others.  For example,  <ins> if an application is using UDP, it could require control over the </ins> checksum or fragmentation behavior for UDP; if it used a protocol to frame its data over a byte stream like TCP, it would not need these options.  In such cases, the API should expose the features in such a way that they take effect when a particular protocol is selected, but  <ins> do not imply that only that protocol could be used if there are </ins> equivalent options. Other specialized features, however, may be strictly required by an possible that some very constrained devices might not have, for example, a full TCP implementation.  <ins> To preserve flexibility and compatibility with future protocols, top- level features in the Transport Services API should avoid referencing particular transport protocols.  The mappings of these API features to specific implementations of each feature is explained in the TAPS- IMPL, which also explain the implications of the feature provided by existing protocols.  It is expected that this document will be updated and supplemented as new protocols and protocol features are developed. </ins> It is important to note that neither the Transport Services API nor the Implementation document defines new protocols that require any  <ins> changes to a remote host.  The Transport Services system must be </ins> deployable on one side only, as a way to allow an application to make better use of available capabilities on a system and protocol features that may be supported by peers across the network.