Change:
I'm having difficult parsing "At this point, any constraints or requirements the application may have on the connection are available from pre-establishment." I'm not even sure what meaning is intended. Available? To what and for what? Is this really a forest? I.e., is a possible when, for instance, you have a choice of two hostnames? If so, there should be an example illustrating that. The last example in the section should be augmented to show multiple hostnames as described by the preceding paragraph. Additionally, I think stating that there is a clear/natural dependency relationship between branching operations such that later operations depend on earlier decisions could simplify and clarify the justification for the suggested order of operations. "Scavenger" implies LEDBAT to me: it will take whatever is currently not being used but will defer to everything else. I'm not sure that notion aligns with the preference described. Is the intent of: that a protocol higher in the stack (or a framer?) could use 0-RTT even if the application doesn't want 0-RTT? Are there any security or privacy implications to this? Should there be a mechanism to disable this entirely? I do not understand the syntax employed here. Is in: a global object or something? It appears to be generating a Start event with the Connection object to the system, but isn't the framer the receiver of such an event? (Nit: isn't Event<> with angle brackets the syntax here?) doesn't seem quite right. Protocols possess a property of application-layer data unit, usually as an intrinsic property that is a direct consequence of the protocol design. They don't really define it so much as end up with it. Maybe this is too much of a nit, but it reads weirdly. The use of "unconnected" (or "connectionless") directly adjacent to the phrase "UDP connections" is driving me batty. I understand that the TAPS interface provides only a Connection object, but we should not ever use lowercase-c "connection" to refer to UDP, and be clear when we mean the uppercase-C "Connection" object in relation to an underlying UDP transport.
I rust just read this as "The Implementation now has all constrains it needs to know for attempting to establish a connection in the form of Preconnection parameters (endpoints, security parameters and transport properties) and can now continue." I would imagine that if 0-RTT is set to prohibit that applies to the entire stack (including framers). This is a bit confusing, but basically, as far as I understand, there is the MessageFramer which is part of the TAPS Implementation (this creates the events and has the methods MakeConnectionReady, MakeConnectionClosed etc.) and there is the framer implementation (which is the part the users of the TAPS implementation write themselves, this receives the events and then calls the methods on the MessageFramer). It might be good to find another term for MessageFramer to make that difference more clear.
WFM

Discussion:
The process of establishing a network connection begins when an application expresses intent to communicate with a Remote Endpoint by <del> calling Initiate.  (At this point, any constraints or requirements the application may have on the connection are available from pre- establishment.)  The process can be considered complete once there is at least one Protocol Stack that has completed any required setup to the point that it can transmit and receive the application's data. </del> <ins> calling Initiate, at which point the Preconnection object contains all constraints or requirements the application has configured for the connection.  The establishment process can be considered complete once there is at least one Protocol Stack that has completed any required setup to the point that it can transmit and receive the application's data. </ins> Connection establishment is divided into two top-level steps: Candidate Gathering, to identify the paths, protocols, and endpoints

The rest of this section will use a notation scheme to represent this tree.  The parent (or trunk) node of the tree will be represented by <del> a single integer, such as "1".  Each child of that node will have an integer that identifies it, from 1 to the number of children.  That child node will be uniquely identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: </del> <ins> a single integer, such as "1". ("1" is used assuming that this is the first connection made by the system; future connections created by the application would allocate numbers in an increasing manner.) Each child of that node will have an integer that identifies it, from 1 to the number of children.  That child node will be uniquely identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: </ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer

"Capacity Profile": An implementation can use the Capacity Profile to prefer paths that match an application's expected traffic pattern.  This match will use cached performance estimates, see <del> performance-caches: Scavenger: Prefer paths with the highest expected available capacity, but minimising impact on other traffic, based on the observed maximum throughput; </del> <ins> performance-caches.  Some examples of path preferences based on Capacity Profiles include: </ins> Low Latency/Interactive: Prefer paths with the lowest expected Round Trip Time, based on observed round trip time estimates;

Round Trip Time, but can tolerate delay variation; Constant-Rate Streaming: Prefer paths that are expected to <del> satisy the requested Stream Send or Stream Receive Bitrate, </del> <ins> satisfy the requested Stream Send or Stream Receive Bitrate, </ins> based on the observed maximum throughput; Capacity-Seeking: Prefer adapting to paths to determine the

it to each new leaf node that is started and for which a protocol instance supporting 0-RTT is being used. <del> It is also possible that Protocol Stacks within a particular leaf node use 0-RTT handshakes without any safely replayable application data.  For example, TCP Fast Open could use a Client Hello from TLS </del> <ins> It is also possible for Protocol Stacks within a particular leaf node to use 0-RTT handshakes without any safely replayable application data if a protocol in the stack has idempotent handshake data to send.  For example, TCP Fast Open could use a Client Hello from TLS </ins> as its 0-RTT data, shortening the cumulative handshake time. 0-RTT handshakes often rely on previous state, such as TCP Fast Open

can support cloning new Connection objects without a new explicit handshake. <del> Protocols also define a notion of Data Unit.  Possible values for Data Unit are: </del> <ins> Protocols also have a notion of Data Unit.  Possible values for Data Unit are: </ins> Byte-stream.  Byte-stream protocols do not define any Message boundaries of their own apart from the end of a stream in each

API mappings for UDP are as follows: <del> UDP connections represent a pair of specific IP addresses and </del> <ins> UDP Connections represent a pair of specific IP addresses and </ins> ports on two hosts. CONNECT.UDP.  Calling "Initiate" on a UDP Connection causes it to