Draft: draft-ietf-taps-interface

Commentary: 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 is n't IMO necessary . ) 
  , 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 .
Paragraph (version B):
security protocol should work in a TAPS system.  Security
consideration for these protocols should be discussed in the
respective specifications.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.