Original text:
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>  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>  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>  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

Reviewer comments:
This changes the use of the term "entanglement" as discussed in , and moves some text around in this section for better clarity and less repetition. Also, addressing , it introduces a framer as an optional parameter to the Clone call.
NAME I incorporated all of your suggestions, thanks!
This is not fully clear from section 5.4., however, if connections in a group are each QUIC streams, I think it should be possible to use different framers on each stream. So it might be okay that a framers is copied when clone is called but changing a framer on one connection should not change the framer on the other connection in a group...?
Also an related editorial comment (that could be addressed in the same PR eventually): this section on groups only at the very end has a paragraph starting with "Note that calling Clone() can result in on-the-wire signaling..." which kind of explains that groups are supposed to be used for multistream protocol but can also be mapped to separate connection if the protocol doesn't not support multiplexing of stream on one connection. I think this information should be added at the very beginning of this section.
Actually, now looking at the framer section, I guess you would rather like to already set the new framer before you clone a connection...?
I agree with everything you say here; about your last suggestion, maybe a framer should be an optional argument of the clone call?
I don’t actually understand the difference between a connection in a Connection Group and an “entangled connection” ? Both terms are used in API, but in different ways (possibly by different authors) - do we really really need the word “entangled”?? if we do we need, can we define and explain this.
I think that having the word is good as it indicates a deeper relationship than mere "grouping". Just based on terms, I'd (correctly) imagine that I can define priorities between members of a group, and that they somehow belong together... as in: Close with a common call, etc. ... but I don't think that I would expect, just from this term, that changing a property on one of them affects all the others. Hence the phrasing: "The connections within a group are 'entangled' with each other". However, I agree that in most other places, we should talk about "groups" instead. 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.

Revised text:
is just a new stream of an already active multi-streaming protocol instance.  If the underlying protocol supports multi-streaming, it is natural to  <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.,  <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:  <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