Code change:
3.3. <del> The Transport Services API is envisioned as the abstract model for a family of APIs that share a common way to expose transport features and encourage flexibility.  The abstract API definition I-D.ietf- taps-interface describes this interface and how it can be exposed to application developers. Implementations that provide the Transport Services API I-D.ietf- taps-impl will vary due to system-specific support and the needs of the deployment scenario.  It is expected that all implementations of Transport Services will offer the entire mandatory API.  All implementations are expected to offer an API that is sufficient to use the distilled minimal set of features offered by transport protocols I-D.ietf-taps-minset, including API support for TCP and UDP transport.  However, some features provided by this API will not be functional in certain implementations.  For example, it is possible that some very constrained devices might not have a full TCP implementation beneath the API. To preserve flexibility and compatibility with future protocols, top- level features in the Transport Services API ought to avoid referencing particular transport protocols.  The mappings of these API features to specific implementations of each feature is explained in the I-D.ietf-taps-impl along with the implications of the feature on existing protocols.  It is expected that I-D.ietf-taps-interface will be updated and supplemented as new protocols and protocol features are developed. </del> <ins> A Transport Services implementation can select Protocol Stacks based on the Properties communicated by the application.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same transport properties and interface expectations as requested by the application. The following two examples show non-equivalent Protocol Stacks: If the application requires preservation of message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is not equivalent to a Protocol Stack that runs TCP as the top-level interface.  A UDP stack would allow an application to read out message boundaries based on datagrams sent from the remote system, whereas TCP does not preserve message boundaries on its own, but needs a framing protocol on top to determine message boundaries. If the application specifies that it requires reliable transmission of data, then a Protocol Stack using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP. The following example shows equivalent Protocol Stacks: If the application does not require reliable transmission of data, then a Protocol Stack that adds reliability could be regarded as an equivalent Protocol Stack as long as providing this would not conflict with any other application-requested properties. To ensure that security protocols are not incorrectly swapped, Transport Services systems MUST only select Protocol Stacks that meet application requirements (I-D.ietf-taps-transport-security).  Systems SHOULD only race Protocol Stacks where the transport security protocols within the stacks are identical.  Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols.  A Transport Services system MAY allow applications to explicitly specify that fallback to a specific other version of a protocol is allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not available. 3.4. </ins> 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 is communicated across the network.  Use of a Transport Services <del> system does not require that a peer on the other side of a connection </del> <ins> system MUST NOT require that a peer on the other side of a connection </ins> uses the same API or implementation.  A Transport Services system <del> 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 that implement the protocol, independent of whether the initiator uses Transport Services as well or not. </del> <ins> acting as a connection initiator is able to communicate with any existing system that implements the transport protocol(s) and all the required properties 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 that implement the protocol, independent of whether the initiator uses a Transport Services system or not. In normal use, a Transport Services system SHOULD result in consistent protocol and interface selection decisions for the same network conditions given the same set of Properties.  This is intended to provide predictable outcomes to the application using the API. </ins> 4.

Related discussion:
text: A Transport Services system automates the selection of protocols and features and network, based on a set of Properties supplied through the TAPS interface. It is RECOMMENDED that a Transport Services system offers Properties that are common to multiple transport protocols. Specifying common Properties enables a system to appropriately select between protocols that offer equivalent features. This design permits evolution of the transport protocols and functions without affecting the programs using the system. Specifying common Properties enables a Transport Services system to appropriately select an appropriate network interface. It is RECOMMENDED that a system offers Properties that are common to a variety network layer interfaces and paths. This design permits racing of different network paths without affecting the programs using the system. Applications using the Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system, including the possibility to express requirements and preferences that constrain the choices that can be made by the system. If two different Protocol Stacks can be safely swapped, or raced in parallel (see Section 4.2.2), by the Transport Services system then they are considered to be "equivalent". Equivalent Protocol Stacks need to meet the requirements for racing specified in section XX. Applications using a Transport Services system MAY explicitly require or prevent the use of specific transport features (and transport protocols) and XXXinterfaces using the "REQUIRED" and "PROHIBIT" preferences. This allows an application to constrain the set of protocols and features that will be selected for the transport service. It is RECOMMENDED that the default usage by applications does not necessarily restrict this selection, so that the system can make informed choices (e.g., based on the availability of interfaces or set of transport protocols available for the specified remote endpoint). When a Transport Services system races between two different Protocol Stacks, both SHOULD use the same security protocols and options. However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols. A Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. It is RECOMMENDED that in normal use, a Transport Services system is designed so that all selection decisions result in consistent choices for the same network conditions when they have the same set of preferences.