performance and functional characteristics; and it can communicate with different remote systems to optimize performance, robustness to failure, or some other metric.  Beyond these, if the API for the <del> system remains the same over time, new protocols and features could be added to the system's implementation without requiring changes in </del> <ins> system remains the same over time, new protocols and features can be added to the system's implementation without requiring changes in </ins> applications for adoption. <del> 3.1. </del> <ins> The normative requirements described here allow Transport Services APIs and Implementations to provide this functionlity without causing incompatibility or introducing security vulnerabilities.  The rest of this document describes the architecture non-normatively. </ins> <del> Functionality that is common across multiple transport protocols ought to be accessible through a unified set of API calls.  An application using a Transport Services API can implement logic for its basic use of transport networking (establishing the transport, and sending and receiving data) once, and expect that implementation to continue to function as the transports change. </del> <ins> 3.1. </ins> <del> As a baseline, any Transport Services API needs to allow access to the distilled minimal set of features offered by transport protocols </del> <ins> Any functionality that is common across multiple transport protocols SHOULD be made accessible through a unified set of Transport Services API calls.  As a baseline, any Transport Services API MUST allow access to the minimal set of features offered by transport protocols </ins> I-D.ietf-taps-minset. <ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via Properties.  A Transport Services API SHOULD offer Properties that are common to multiple transport protocols, in order to enable the system to appropriately select between protocols that offer equivalent features.  Similarly, a Transport Services API SHOULD offer Properties that are applicable to a variety of network layer interfaces and paths, in order to permit racing of different network paths without affecting the applications using the system.  Each Property is expected to have a default value. The default values for Properties SHOULD be selected to ensure correctness for the widest set of applications, while providing the widest set of options for selection.  For example, since both applications that require reliability and those that do not require reliability can function correctly when a protocol provides reliability, reliability ought to be enabled by default.  As another example, the default value for a Property regarding the selection of network interfaces ought to permit as many interfaces as possible. 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. </ins> 3.2. There are applications that will need to control fine-grained details of transport protocols to optimize their behavior and ensure compatibility with remote systems.  A Transport Services system <del> therefore ought to also permit more specialized protocol features to be used.  The interface for these specialized options ought to be exposed differently from the common options to ensure flexibility. </del> <ins> therefore SHOULD permit more specialized protocol features to be used. </ins> A specialized feature could be required by an application only when using a specific protocol, and not when using others.  For example,