Original text:
configuration details for transport security protocols, as discussed in security-parameters.  It does not recommend use (or disuse) of specific algorithms or protocols.  Any API-compatible transport <del> security protocol should work in a TAPS system. </del> 

Reviewer comments:
This ended up in more text that I thought. I'm not certain if we need all of it. Further I'm unsure about the concrete wording in many cases, so any comments are more than welcome!
This is supposed to address issue
I do mentioned name resolution, however, leakage though DNS might rather be a DNS problem and not necessarily an issue that needs to be considered in taps. Sharing cache state is a good point. I vaguely remember that we already address that somewhere else (could also be in the implementation draft as this is rather an implementation issue). But maybe we can add a pointer...?
Leakage though DNS may need to be addressed by TAPS, as with the current sockets API, the application has complete control about when DNS resolution is done (and, at least as long as things like DoH/DoT are predominantly implemented by nonsystem resolver libraries, how). TAPS as envisioned gives the system more control over resolution.
(IIRC the architecture does explicitly address and mention the shared cache issue; adding a line to refer to that in privacy considerations might be nice but isn't IMO necessary.)
Gorry, I addressed all your nits/comments.
I think it is a good start, but I miss two aspects: Information leakage through DNS, which can also make addresses on different paths linkable Information leakage within an application though shared caches, e.g., within a browser. I agree this is a good starting point; note that I took the liberty to directly fix some nits (such as capitalizing TAPS) and typos; these never change the intended meaning.

Revised text:
configuration details for transport security protocols, as discussed in security-parameters.  It does not recommend use (or disuse) of specific algorithms or protocols.  Any API-compatible transport  <ins> security protocol should work in a TAPS system.  Security consideration for these protocols should be discussed in the respective specifications. The desribed API is used to exchange information between an application and the transport system.  While it is not necessarily expected that both systems are implemented by the same authority, it is expected that the transport system implementation is either provided as a library that is selected by the application from a trusted party, or that it is part of the operating system that the application also relies on for other tasks. In either case, the TAPS API is an internal interface that is used to change information locally between two systems.  However, as the transport system is responsible for network communication, it is in the position to potentially share any information provided by the application with the network or another communication peer.  Most of the information provided over the TAPS API are useful to configure and select protocols and paths and are not necessarily privacy sensitive.  Still, there is some information that could be privacy sensitve because this might reveal usage characteristics and habits of the user of an application. Of course any communication over a network reveals usage characteristics, as all packets as well as their timing and size are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which information is visible, potentially in clear text, and which other enties can access it.  In most cases information that is provided for protocol and path selection should not directly translate to information that is can be observed by network devices on the path. But there might be specific configuration information that are intended for path exposure, such as e.g. a DiffServ codepoint setting, that is either povided directly by the application or indirectly configured over a traffic profile. Further, applications should be aware that communication attempts can lead to more than one connection establishment.  This is for example the case when the transport system also excecutes name resolution; or when support mechanisms such as TURN or ICE are used to establish connectivity; or if protocols or paths are raised; or if a path fails and fallback or re-establishment is supported in the transport system. These communication activities are not different from what is used today, however, the goal of a TAPS transport system is to support such mechanisms as a generic service within the transport layer. This enables applications to more dynamically benefit from innovations and new protocols in the transport system but at the same time may reduce transparency of the underlying communication actions to the application itself.  The TAPS API is designed such that protocol and path selection can be limited to a small and controlled set if required by the application for functional or security purposes.  Further, TAPS implementations should provide an interface to poll information about which protocol and path is currently in use as well as provide logging about the communication events of each connection. </ins>