Draft: draft-ietf-taps-interface

Commentary: Fix terminology in -arch Add minimal connection contexts in -interface 
 We had not decided that yet : We agreed that the property was sufficient as portable interface for the purpose We did not yet because did nit fix the inconsistencies between Connection Groups in -architecture and -interface So what we could do ( als an alternative to this PR ) to - Drop the stuff this PR renamed to " Connection Context " from -arch all - together Merge the changes in -arch , but do not include the minimal   into -interface an try to squish question about the context missing in -interface in later reviews 
 Connection Groups used to be about state and context sharing as well as entanglement . Now it 's about entanglement . We need to rename Connection Groups ( " connection contexts " ? ) in the architecture to replace the existing " group " concept , and to retain " connection group " in the API for entanglement . 
 Seems like this could be 360 degrees of rotation in our thinking ? ( which could be OK , NEAT was written to specify both contexts and flow groups ) . Let 's try some definitions here and see if we converge ... 
 I think brings this back in synch again so no need to rename , possibly the last part of this section in architecture should be removed though as we do not have fine - grained control 
 Did we decide to explicitly introduce this new connection context ?
Paragraph (version A):
When set to true, this property will initiate new Connections using
as little cached information (such as session tickets or cookies) as
possible from previous connections that are not entangled with it.
Any state generated by this Connection will only be shared with
entangled connections.  Cloned Connections will use saved state from
within the Connection Group.
Paragraph (version B):
When set to true, this property will initiate new Connections using
as little cached information (such as session tickets or cookies) as
possible from previous connections that are not entangled with it.
Any state generated by this Connection will only be shared with
entangled connections.  Cloned Connections will use saved state from
within the Connection Group.  This is used for separating Connection
Contexts as specified in I-D.ietf-taps-arch.
Paragraph (version A):
A Connection Group is a set of Connections that share properties and
caches.  For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed
together.  An application can explicitly define Connection Groups to
control caching boundaries, as discussed in groups.
Paragraph (version B):
A Connection Group is a set of Connections that shares properties and
caches.  For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed
together.  While Connection Groups are managed by the transport
system, an application can define Connection Contexts to control
caching boundaries, as discussed in conn-context.
Paragraph (version A):
The Transport Services API can allow applications to explicitly
define Connection Groups that force separation of Cached State and
Protocol Stacks.  For example, a web browser application might use
Connection Groups with separate caches for different tabs in the
browser to decrease linkability.
Paragraph (version A):
The interface to specify a Connection Group can expose fine-grained
tuning for which properties and cached state is allowed to be shared
with other Connections.  For example, an application might want to
allow sharing TCP Fast Open cookies across groups, but not TLS
session state.
Paragraph (version B):
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.