Draft: draft-ietf-taps-arch

Commentary: Addressed MW comments ; and also tidied several successive similar examples into one para . 
 Section 4.2.3 , item 3 : " Performance concerns about Connections introducing head - of - line blocking due to multiplexing or needing to share state on a single thread . " I do n't think application programmers should decide against using functions such as   because they try to optimize their performance in this way . If it performs poorly , the Transport Services system should n't do it . I know this is n't always black and white ... I 'm guessing that this was written with HTTP/2 in mind . Still ... if a mechanism is judged as generally performing better most of the time , the system should probably use it . If it does n't perform better e.g. depending on the length of transfers , which may be known from HTTP header , then maybe the Transport Services system is the ideal place to dynamically make such a decision ? Anyway - I do n't think that we should indirectly suggest to application writers that internal functions chosen by the Transport Services system on the basis of high - level information like " these Connections belong together " might in fact perform poorly , and hence they may be better off not using them if they want the best performance for their application . So , I would remove this item . 
 Sure , applications might do many things and some decisions to multiplex multiple flows using a single protocol instantiation might be less performance , however , I would suggest removing this bullet : " * Performance concerns about Connections introducing head - of - line blocking due to multiplexing or needing to share state on a single thread . " , because I think it creates confusion as  suggests . A developer understanding complex tradeoffs ( such as web client browsers or NFS / SMB servers ) will consider this anyway , others should not be worried .
Paragraph (version A):
Privacy concerns about re-using cached protocol state that can
lead to linkability.  Sensitive state may include TLS session
state RFC8446 and HTTP cookies RFC6265.
Paragraph (version A):
Privacy concerns about allowing Connections to multiplex together,
which can tell a Remote Endpoint that all of the Connections are
coming from the same application (for example, when Connections
are multiplexed HTTP/2 or QUIC streams).
Paragraph (version A):
Performance concerns about Connections introducing head-of-line
blocking due to multiplexing or needing to share state on a single
thread.
Paragraph (version A):
The Transport Services API can allow applications to explicitly
define Connection Contexts that force separation of Cached State and
Protocol Stacks.  For example, a web browser application might use
Connection Contexts with separate caches for different tabs in the
browser to decrease linkability.
Paragraph (version B):
Privacy concerns about re-using cached protocol state that can
lead to linkability.  Sensitive state could include TLS session
state RFC8446 and HTTP cookies RFC6265.  These concerns could be
addressed using Connection Contexts with separate caches, such as
for different browser tabs.
Paragraph (version B):
Privacy concerns about allowing Connections to multiplex together,
which can tell a Remote Endpoint that all of the Connections are
coming from the same application.  Using Connection Contexts
avoids the Connections being multiplexed in a HTTP/2 or QUIC
stream.