Original text:
without requiring changes to the applications.  The specified API follows the Transport Services Architecture by providing asynchronous, atomic transmission of messages.  It is intended to <del> replace the traditional BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. </del>  1. <del> This document specifies a modern abstract application programming interface (API) atop the high-level architecture for transport services defined in I-D.ietf-taps-arch.  The Transport Services Architecture supports asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime, in environments where an endpoint selects from multiple interfaces and potential transport protocols. </del>  Applications that adopt this interface will benefit from a wide set of transport features that can evolve over time.  This protocol- This API derives specific path and protocol selection properties and supported transport features from the analysis provided in RFC8095, <del> RFC8923, and RFC8922.  The design encourages implementations underneath the interface to dynamically choose a transport protocol depending on an application's choices rather than statically binding applications to a protocol at compile time.  Nevertheless, the Transport Services API also provides applications with a way to override transport selection and instantiate a specific stack, e.g., to support servers wishing to listen to a specific protocol. However, forcing a specific transport stack choice is discouraged for general use, because it can reduce portability. </del>  1.1. Asynchronous Connection establishment, transmission, and reception.  This allows concurrent operations during establishment and event-driven application interactions with the transport <del> layer, in line with developments in modern platforms and programming languages; </del>  Selection between alternate network paths, using additional information about the networks over which a connection can operate

Reviewer comments:
Reconsider words like "atop" and "underneath" when talking about interface boundaries. (Also, I don't know what it means to be atop an architecture.)
There are several places where the language in this document, once published as an RFC, will not age well. Search for occurrences of the word "modern" and consider writing less to motivate and more to define. Reconsider the use of terms like "traditional".
In 3.1 consider "It is important for applications using a Transport Services system to be robust to the" instead of using REQUIRED. At 3.2, if this were a requirements document for the Transport Services system, the SHOULD in the first paragraph might make sense. But if its an architecture document, or better, an overview and introduction. It would be better to simply say "is" rather than SHOULD. (And in a requirements document, I would argue that this SHOULD should be a MUST).
I think 3.1 probably needs a little more unpacking, this is a little abstarct in what is needed to say required: "Applications using a Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system, where the automated selection is constrained by the requirements and preferences expressed by the application." We could therefore loose the /REQUIRED/. I'll suggest this as a starting point for 3.1 - the topic here is not an interoperability requirement of the protocol on the wire, it is about whether the method needs to have the feature to satisfy the design goals: "It is therefore is RECOMMENDED that a Transport Services system permits more specialized protocol features to be used."
this will be fixed with any reasonable fix to
Early art-art review of draft-ietf-taps-architecture My first observation and request is that the group rethink the separation of the architecture and interface documents. It is a warning-sign that the interface document is a normative reference for the architecture document. As the documents are currently constructed, a new reader cannot grasp the architecture without inferring some of it through reading the interface. Consider reformulating the architecture document as an overview - introduce principles, concepts, and terminology, but don't attempt to be normative. (There are signs that this may already be, or have been, a path the document was being pushed towards). If nothing else, rename it, and acknowledge that the actual architecture is specified using the interface definition. Note that the first sentence of the Overview in the interface document also highlights the current structural problem.
I don't entirely agree with this ART-ART comment: I think I might well agree with moving more of the description to this Arch document, but as discussed before, I also think it useful here to set the actual requirements for the architecture, and to define the architecture. It may need to be much clearer that this architecture consists of more the API.
For completeness, this is the first statement of the interface document review: This document reads fairly well. I have some structural concerns (see the early review of the architecture document). In particular I think this document contains the actual definition of the architecture and some of that is inferential.
Discussion at September 2021 interim: pass through this document with a view toward making it a high level introduction, not an architecture definition: "An Introduction to the Transport Services Architecture". remove normative language from this document (moving it to API, where necessary). move details not useful in a high level intro to API.
I disagree with this conclusion at first pass—we did a specific analysis and pass on this over a year ago, with PR . The normative language and the standards-track aspect was very intentional and something the WG had consensus on. The point is that the API is a specific incarnation of the TAPS architecture, but there are overarching architectural properties that go beyond a specific abstract API.
I completely agree with Tommy here, and recommend we fix this in . We should also of course check for any stray text or missing concepts. I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system.
See linked PR first please to see if this resolves this?
A PR was merged that addressed important text issues with separation of requirements and overview, and should more clearly set out that the requirements are for the system. The question of whether the overall TAPS systems requirements belong in this ID; the API; or a separate RFC needs some discussion based on the review, before this can be closed.
Many good text improvements in the PR NAME but I noticed two smaller updates in the PR that I think were incorrect. Fixed in
The review comment showed were many places where the wording of architecture can be improved. There are some high level principles that I think should remain in the architecture document. The decision in today's interim is to review the architecture to get this more into a shape that is valuable as a reference, and then check the updated draft.
I now suggest the issues are addressed and we close this issue without moving text between documents
I agree with that; closing.
Small fix for Gorry's comment suggested.

Revised text:
without requiring changes to the applications.  The specified API follows the Transport Services Architecture by providing asynchronous, atomic transmission of messages.  It is intended to  <ins> replace the BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. </ins> 1.  <ins> This document specifies an abstract application programming interface (API) that specifies the interface component of the high-level architecture for transport services defined in I-D.ietf-taps-arch. The Transport Services Architecture supports asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime, in environments where an endpoint selects from multiple interfaces and potential transport protocols. </ins> Applications that adopt this interface will benefit from a wide set of transport features that can evolve over time.  This protocol- This API derives specific path and protocol selection properties and supported transport features from the analysis provided in RFC8095,  <ins> RFC8923, and RFC8922.  The design encourages implementations that provide the interface to dynamically choose a transport protocol rather than statically binding applications to a protocol at compile time.  Nevertheless, the Transport Services API also provides applications with a way to override transport selection and instantiate a specific stack, e.g., to support servers wishing to listen to a specific protocol.  However, forcing a specific transport stack choice is discouraged for general use, because it can reduce portability. </ins> 1.1. Asynchronous Connection establishment, transmission, and reception.  This allows concurrent operations during establishment and event-driven application interactions with the transport  <ins> layer; </ins> Selection between alternate network paths, using additional information about the networks over which a connection can operate