Code change:
is just a new stream of an already active multi-streaming protocol instance. <del> Changing one of the Connection Properties on one Connection in the group changes it for all others.  Message Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Connection Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- lifetime) of a Message will only affect a single Message on a single Connection, entangled or not. </del> If the underlying protocol supports multi-streaming, it is natural to <del> use this functionality to implement Clone.  In that case, entangled Connections are multiplexed together, giving them similar treatment not only inside endpoints, but also across the end-to-end Internet path. </del> <ins> use this functionality to implement Clone.  In that case, Connections in a Connection Group are multiplexed together, giving them similar treatment not only inside endpoints, but also across the end-to-end Internet path. </ins> Note that calling Clone() can result in on-the-wire signaling, e.g., <del> to open a new connection, depending on the underlying Protocol Stack. When Clone() leads to multiple connections being opened instead of multi-streaming, the Transport Services system will ensure consistency of Connection Properties by uniformly applying them to all underlying connections in a group.  Even in such a case, there are possibilities for a Transport Services system to implement prioritization within a Connection Group TCP-COUPLING RFC8699. </del> <ins> to open a new transport connection, depending on the underlying Protocol Stack.  When Clone() leads to the opening of multiple such connections, the Transport Services system will ensure consistency of Connection Properties by uniformly applying them to all underlying connections in a group.  Even in such a case, there are possibilities for a Transport Services system to implement prioritization within a Connection Group TCP-COUPLING RFC8699. </ins> Attempts to clone a Connection can result in a CloneError: <del> The Connection Priority Connection Property operates on entangled Connections using the same approach as in msg-priority: when allocating available network capacity among Connections in a </del> <ins> The "Connection Priority" Connection Property operates on Connections in a Connection Group using the same approach as in msg-priority: when allocating available network capacity among Connections in a </ins> Connection Group, sends on Connections with lower Priority values will be prioritized over sends on Connections with higher Priority values.  Capacity will be shared among these Connections according to

Related discussion:
text: I can try to fix this.
Sounds good - we should add that explanation upfront in the definitions then also?
[Yes, I think so.] EDIT: no, now I don't think so anymore. (see )
I have addressed this in PR . Note that the text interchangeably talked about both Connections and Connection Properties as being "entangled". I have now written this such that the term "entanglement" applies to Connection Properties only, whereas Connections in a group are, well, members of the same Connection Group.
Looks good to me.