Original text:
Connection.  These connections are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these two Connections adds a third Connection to the Connection Group, and so <del> on.  Connections in a Connection Group share all Protocol Properties that are not applicable to a Message. </del>  In addition, incoming entangled Connections can be received by creating a Listener on an existing connection: <del> Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol 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 Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </del>  lifetime) of a Message will only affect a single Message on a single Connection, entangled or not. create a new stream on the given Connection, then attempts to clone a Connection will result in a CloneError: <del> The Protocol Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </del>  Connections in a Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections with lower Priority values.  An ideal transport system implementation 11.1. <del> The Connection Properties defined as independent, and available on all Connections are defined in the subsections below. </del>  <del> Note that many protocol properties have a corresponding selection property, which prefers protocols providing a supporting transport feature. </del>  11.1.1.

Reviewer comments:
When reading the API draft, I noticed that in some places it was still using the outdated term "Protocol Properties" where it actually means Connection Properties or Message Properties. I replaced the terms in this PR. We do still define "Specific Protocol Properties", so I kept these.

Revised text:
Connection.  These connections are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these two Connections adds a third Connection to the Connection Group, and so  <ins> on.  Connections in a Connection Group generally share Connection Properties.  However, there may be exceptions, such as "Priority (Connection)", see conn-priority. </ins> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection:  <ins> 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- </ins> lifetime) of a Message will only affect a single Message on a single Connection, entangled or not. create a new stream on the given Connection, then attempts to clone a Connection will result in a CloneError:  <ins> The Connection Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </ins> Connections in a Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections with lower Priority values.  An ideal transport system implementation 11.1.  <ins> The Connection Properties defined as independent of the chosen protocol stack, and available on all Connections are defined in the subsections below. </ins>  <ins> Note that many Connection Properties have a corresponding Selection Property, which enables applications to express their preference for protocols providing a supporting transport feature. </ins> 11.1.1.