Change:
, , , . Partially addresses . A few comments: : Kyle's comment addressed ("Connection Properties can be set on Preconnections" fixed to "Connection Properties can be set on Preconnections and Connections") : I don't think the sentence explaining what an application could do upon an establisment error is necessary. I removed it, and now the text should be clearer. : All Connection Properties but "Priority (Connection)" are entangled. This is now clearly stated, not mentioned as an example. : Great catch. I now replaced this with an example that talks about ordering (clearly, requiring ordering from UDP will have to fail). : Reworded all the bits you point out, hopefully it's all clearer now. : first, there was a broken sentence, which seemed to miss "will not occur", so I added this. Then, I removed the last sentence which had the contradictory "ConnectionError<> can occur after Closed<>, ..." statement.
contradicts itself in one paragraph: It seems like Closed<> can and should be it: the stack should refuse any further interaction with userspace for this connection after that point.
says: The transport system can't ensure that: it can ensure that either the message is delivered before clean shutdown or the connection will be broken without a clean shutdown. Later, it says: "Deliver" in the context of transports is a term of art that means "the stack handed the data over to the application". The local endpoint has no way of knowing when or if this has happened: the remote endpoint will happily ACK packets until the rxbuf is full, without delivering a single byte of data to the application. What is the actual condition under which this will fire? I think this wants to be more general, because this will happen (e.g., in TCP) even if a MITM sends a RST. Maybe just "the connection is otherwise broken".
Why? Even an unreliable connection can block forever if congestion control is in place. Maybe a better illustration is: what should the TTL on a UDP message be? Is there a maximum? If so, how do you know what it is or specify it? Maybe a better example is warranted here.
"Entangled" appears eight times in the doc and its effect is never precisely defined. The doc should specify in an easily-consumable format (e.g., a table, but not necessarily a table) exactly which properties are shared between cloned connections and which aren't.
I am having difficult parsing:
: "Although Connection Properties (see Section 7.1) can be set during pre-establishment, they may be changed later." Four sentences later: "Connection Properties can be set on Preconnections"
Unrelated, but about the same text: I notice something weird here, regarding compilation. Looking at https://ietf-URL I see: ... which is broken at the end. However, looking at URL I see: They are used to inform decisions made during establishment and to fine-tune the established connection. The behavior of the selected protocol stack(s) when sending Messages is controlled by Message Properties (see {{message-props}}). ... which is much better. Since the last manual commit is 2 days ago, this must be a strange compilation mistake.
PR has addressed Kyle's point - so this is now about something else. Please see my comment above.
The file is the correct copy. We can close this.

Discussion:
used, are organized within a single namespace.  This enables setting them as defaults at earlier stages and querying them in later stages: <del> Connection Properties can be set on Preconnections </del> <ins> Connection Properties can be set on Preconnections and Connections </ins> Message Properties can be set on Preconnections, Connections and Messages

connection.  Using the same default values for independent Transport Services implementations can be beneficial when applications are ported between different implementations/platforms, even if this <del> default could lead to a connection failure, as, for example, an application needs to be explicitly designed to support a connectionless mode.  In this case, the application can recognize the failure and explicitly specify a different set of Protocol Selection Properties that result in a usable protocol.  If default values other than those recommended below are used, it is recommended to clearly document any differences. </del> <ins> default could lead to a connection failure when TCP is not available. If default values other than those recommended below are used, it is recommended to clearly document any differences. </ins> 5.2.1.

Connection.  The connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, <del> and so on.  Connections in a Connection Group generally share Connection Properties.  However, there may be exceptions, such as "Priority (Connection)", see conn-priority.  Like all other </del> <ins> and so on.  "Entangled" Connections share all Connection Properties except "Priority (Connection)", see conn-priority.  Like all other </ins> Properties, Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Priority on one Connection does not change it on the other Connections in the same Connection

The Message Properties could be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given <del> Message is sent.  For example, a Connection must provide reliability to allow setting an infinite value for the lifetime property of a Message.  Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. </del> <ins> Message is sent.  For example, a Protocol Stack must be able to provide ordering if the msgOrdered property of a Message is enabled. Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. </ins> Connection Properties describe the default behavior for all Messages on a Connection.  If a Message Property contradicts a Connection

that were specified regarding the delivery of Messages that the application has already given to the transport system.  For example, if reliable delivery was requested for a Message handed over before <del> calling Close, the transport system will ensure that this Message is indeed delivered.  If the Remote Endpoint still has data to send, it cannot be received after this call. </del> <ins> calling Close, the Closed Event will signify that this Message has indeed been delivered.  If the Remote Endpoint still has data to send, it cannot be received after this call. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close

Abort terminates a Connection without delivering any remaining data: A ConnectionError informs the application that: 1) data could not be <del> delivered after a timeout, or 2) the other side has aborted the Connection.  There is no guarantee that an Abort will indeed be signaled. </del> <ins> delivered to the peer after a timeout, or 2) the Connection has been aborted (e.g., because the peer has called Abort).  There is no guarantee that an Abort will indeed be signaled. </ins> 10.

Connection. No events will occur on a Connection after it is Closed; i.e., <del> after a Closed<> event, an InitiateError<> or ConnectionError<> on that connection.  To ensure this ordering, Closed<> will not occur on a Connection while other events on the Connection are still locally outstanding (i.e., known to the interface and waiting to be dealt with by the application).  ConnectionError<> can occur after Closed<>, but the interface must gracefully handle all cases where the application ignores these errors. </del> <ins> after a Closed<> event, an InitiateError<> or ConnectionError<> will not occur on that connection.  To ensure this ordering, Closed<> will not occur on a Connection while other events on the Connection are still locally outstanding (i.e., known to the interface and waiting to be dealt with by the application). </ins> 11.