Change:
Abstract This document describes an abstract application programming <del> interface, API, to the transport layer, following the Transport Services Architecture.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to 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> <ins> interface, API, to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime.  This API enables faster deployment of new protocols and protocol features 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 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. </ins> 1. This document specifies a modern abstract application programming interface (API) atop the high-level architecture for transport <del> services defined in I-D.ietf-taps-arch.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in environments where an endpoint selects from multiple interfaces and potential transport protocols. As applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the application requirements and network conditions, without requiring changes to the applications.  This flexibility enables faster deployment of new features and protocols.  It can also support applications by offering racing and fallback mechanisms, which otherwise need to be separately implemented in each application. </del> <ins> 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. Applications that adopt this interface will benefit from a wide set of transport features that can evolve over time.  This protocol- independent API ensures that the system providing the interface can optimize its behavior based on the application requirements and network conditions, without requiring changes to the applications. This flexibility enables faster deployment of new features and protocols.  It can support applications by offering racing and fallback mechanisms, which otherwise need to be separately implemented in each application. </ins> It derives specific path and protocol selection properties and supported transport features from the analysis provided in RFC8095, 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 <del> applications to a protocol at compile time.  The Transport Services system implementations should provide applications with a way to </del> <ins> applications to a protocol at compile time.  Nevertheless, the Transport Services API also provides applications with a way to </ins> override transport selection and instantiate a specific stack, e.g., <del> to support servers wishing to listen to a specific protocol.  Such a choice to only permit using a specific transport stack is discouraged for general use, because it can reduce the portability. </del> <ins> 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.

Discussion:
While reviewing for last call, I didn't find the abstract very strong. Given I'm an authors, I thought I make another proposal, however, really just that - a proposal...