Original text:
Services are: the Preconnection, the bundle of Properties that describes the <del> application constraints on the transport; </del>  the Connection, the basic object that represents a flow of data as Messages in either direction between the Local and Remote transfer.  During the process of establishment (conn-establish), the Connection will be unbound to a specific transport flow, since there may be multiple candidate Protocol Stacks being raced.  Once the <del> Connection is established, the object should be considered mapped to a specific Protocol Stack.  The notion of a Connection maps to many different protocols, depending on the Protocol Stack.  For example, the Connection may ultimately represent the interface into a TCP </del>  connection, a TLS session over TCP, a UDP flow with fully-specified local and remote endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an HTTP/2 stream. 3. <del> During pre-establishment the application specifies the Endpoints to be used for communication as well as its preferences via Selection Properties and, if desired, also Connection Properties.  Generally, Connection Properties should be configured as early as possible, because they can serve as input to decisions that are made by the implementation (e.g., the Capacity Profile can guide usage of a protocol offering scavenger-type congestion control). </del>  The implementation stores these properties as a part of the Preconnection object for use during connection establishment.  For an order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. <del> The order of operations for branching, where lower numbers are acted upon first, should be: </del>  Alternate Paths Derived Endpoints <del> Branching between paths is the first in the list because results across multiple interfaces are likely not related to one another: endpoint resolution may return different results, especially when using locally resolved host and service names, and which protocols are supported and preferred may differ across interfaces.  Thus, if multiple paths are attempted, the overall connection can be seen as a race between the available paths or interfaces. </del>  Protocol options are next checked in order.  Whether or not a set of protocol, or protocol-specific options, can successfully connect is the TCP handshake is complete, or it can wait for the TLS handshake to complete as well.  The benefit of declaring completion when the TCP handshake finishes, and thus stopping the race for other branches <del> of the tree, is that there will be less burden on the network from other connection attempts.  On the other hand, by waiting until the TLS handshake is complete, an implementation avoids the scenario in which a TCP handshake completes quickly, but TLS negotiation is either very slow or fails altogether in particular network conditions or to a particular endpoint.  To avoid the issue of TLS possibly failing, the implementation should not generate a Ready event for the Connection until TLS is established. </del>  If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the 4.6.1. Connected protocols such as TCP and TLS-over-TCP have a strong <del> mapping between the Local and Remote Endpoints (five-tuple) and their </del>  protocol connection state.  These map into Connection objects. Whenever a new inbound handshake is being started, the Listener should generate a new Connection object and pass it to the provide the same mechanisms that connected protocols do to offer Connection objects.  Implementations should wait for incoming packets for unconnected protocols on a listening port and should perform <del> five-tuple matching of packets to either existing Connection objects </del>  or the creation of new Connection objects.  On platforms with facilities to create a "virtual connection" for unconnected protocols implementations should use these mechanisms to minimise the handling 4.6.3. <del> Protocols that provide multiplexing of streams into a single five- </del>  tuple can listen both for entirely new connections (a new HTTP/2 stream on a new TCP connection, for example) and for new sub- connections (a new HTTP/2 stream on an existing connection).  If the bandwidth. An implementation should use this information, when possible, to <del> determine preference between candidate paths, endpoints, and protocol </del>  options.  Eligible options that historically had significantly better performance than others should be selected first when gathering candidates (see gathering) to ensure better performance for the

Reviewer comments:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!

Revised text:
Services are: the Preconnection, the bundle of Properties that describes the  <ins> application constraints on, and preferences for, the transport; </ins> the Connection, the basic object that represents a flow of data as Messages in either direction between the Local and Remote transfer.  During the process of establishment (conn-establish), the Connection will be unbound to a specific transport flow, since there may be multiple candidate Protocol Stacks being raced.  Once the  <ins> Connection is established, its interface maps actions and events to the details of the chosen Protocol Stack.  For example, the same Connection object may ultimately represent the interface into a TCP </ins> connection, a TLS session over TCP, a UDP flow with fully-specified local and remote endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an HTTP/2 stream. 3.  <ins> During pre-establishment the application specifies one or more Endpoints to be used for communication as well as protocol preferences and constraints via Selection Properties and, if desired, also Connection Properties.  Generally, Connection Properties should be configured as early as possible, because they can serve as input to decisions that are made by the implementation (e.g., the Capacity Profile can guide usage of a protocol offering scavenger-type congestion control). </ins> The implementation stores these properties as a part of the Preconnection object for use during connection establishment.  For an order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node.  <ins> The order of operations for branching should be: </ins> Alternate Paths Derived Endpoints  <ins> where a lower number indicates higher precedence and therefore higher placement in the tree.  Branching between paths is the first in the list because results across multiple interfaces are likely not related to one another: endpoint resolution may return different results, especially when using locally resolved host and service names, and which protocols are supported and preferred may differ across interfaces.  Thus, if multiple paths are attempted, the overall connection can be seen as a race between the available paths or interfaces. </ins> Protocol options are next checked in order.  Whether or not a set of protocol, or protocol-specific options, can successfully connect is the TCP handshake is complete, or it can wait for the TLS handshake to complete as well.  The benefit of declaring completion when the TCP handshake finishes, and thus stopping the race for other branches  <ins> of the tree, is reduced burden on the network and remote endpoints from further connection attempts that are likely to be abandoned.  On the other hand, by waiting until the TLS handshake is complete, an implementation avoids the scenario in which a TCP handshake completes quickly, but TLS negotiation is either very slow or fails altogether in particular network conditions or to a particular endpoint.  To avoid the issue of TLS possibly failing, the implementation should not generate a Ready event for the Connection until TLS is established. </ins> If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the 4.6.1. Connected protocols such as TCP and TLS-over-TCP have a strong  <ins> mapping between the Local and Remote Endpoints (four-tuple) and their </ins> protocol connection state.  These map into Connection objects. Whenever a new inbound handshake is being started, the Listener should generate a new Connection object and pass it to the provide the same mechanisms that connected protocols do to offer Connection objects.  Implementations should wait for incoming packets for unconnected protocols on a listening port and should perform  <ins> four-tuple matching of packets to either existing Connection objects </ins> or the creation of new Connection objects.  On platforms with facilities to create a "virtual connection" for unconnected protocols implementations should use these mechanisms to minimise the handling 4.6.3.  <ins> Protocols that provide multiplexing of streams into a single four- </ins> tuple can listen both for entirely new connections (a new HTTP/2 stream on a new TCP connection, for example) and for new sub- connections (a new HTTP/2 stream on an existing connection).  If the bandwidth. An implementation should use this information, when possible, to  <ins> influence preference between candidate paths, endpoints, and protocol </ins> options.  Eligible options that historically had significantly better performance than others should be selected first when gathering candidates (see gathering) to ensure better performance for the