Change:
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 Connection Context 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?

Discussion:
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 <del> within the Connection Group. </del> <ins> within the Connection Group.  This is used for separating Connection Contexts as specified in I-D.ietf-taps-arch. </ins> Note that this does not guarantee no leakage of information, as implementations may not be able to fully isolate all caches (e.g.

4.1.8. <del> A Connection Group is a set of Connections that share properties and </del> <ins> A Connection Group is a set of Connections that shares properties and </ins> caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed <del> together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </del> <ins> 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. </ins> 4.2.

thread. The Transport Services API can allow applications to explicitly <del> define Connection Groups that force separation of Cached State and </del> <ins> define Connection Contexts that force separation of Cached State and </ins> Protocol Stacks.  For example, a web browser application might use <del> Connection Groups with separate caches for different tabs in the </del> <ins> Connection Contexts with separate caches for different tabs in the </ins> browser to decrease linkability. <del> 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. </del> 5. RFC-EDITOR: Please remove this section before publication.