Change:
10. <del> The connection establishment process outlined in conn-establish is appropriate for client-server connections, but needs to be expanded in peer-to-peer Rendezvous scenarios, as follows: Gathering Local Endpoint candidates The set of possible Local Endpoints is gathered.  In the simple case, this merely enumerates the local interfaces and protocols, allocates ephemeral source ports.  For example, a system that has WiFi and Ethernet and supports IPv4 and IPv6 might gather four candidate locals (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on WiFi, and IPv6 on WiFi) that can form the source for a transient. If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering phase RFC5245.  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT) and relayed locals (e.g., via a TURN server or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server reflexive locals, or with a TURN server or other relay to derive relayed locals.  It does not involve communication with the Remote Endpoint. Gathering Remote Endpoint Candidates The Remote Endpoint is typically a name that needs to be resolved into a set of possible addresses that can be used for communication.  Resolving the Remote Endpoint is the process of recursively performing such name lookups, until fully resolved, to return the set of candidates for the remote of this connection. How this is done will depend on the type of the Remote Endpoint, and can also be specific to each Local Endpoint.  A common case is when the Remote Endpoint is a DNS name, in which case it is resolved to give a set of IPv4 and IPv6 addresses representing that name.  Some types of remote might require more complex resolution.  Resolving the Remote Endpoint for a peer-to-peer connection might involve communication with a rendezvous server, which in turn contacts the peer to gain consent to communicate and retrieve its set of candidate locals, which are returned and form the candidate remote addresses for contacting that peer. Resolving the remote is _not_ a local operation.  It will involve a directory service, and can require communication with the remote to rendezvous and exchange peer addresses.  This can expose some or all of the candidate locals to the remote. Establishing Connections The set of candidate Local Endpoints and the set of candidate Remote Endpoints are paired, to derive a priority ordered set of Candidate Paths that can potentially be used to establish a Connection. Then, communication is attempted over each candidate path, in priority order.  If there are multiple candidates with the same priority, then connection establishment proceeds simultaneously and uses the transient that wins the race to be established. Otherwise, connection establishment is sequential, paced at a rate that should not congest the network.  Depending on the chosen transport, this phase might involve racing TCP connections to a server over IPv4 and IPv6 RFC8305, or it could involve a STUN exchange to establish peer-to-peer UDP connectivity RFC5245, or some other means. Confirming and Maintaining Connections Once connectivity has been established, unused resources can be released and the chosen path can be confirmed.  This is primarily required when establishing peer-to-peer connectivity, where connections supporting relayed locals that were not required can be closed, and where an associated signalling operation might be needed to inform middleboxes and proxies of the chosen path. Keep-alive messages may also be sent, as appropriate, to ensure NAT and firewall state is maintained, so the Connection remains operational. To support ICE, or similar protocols, that involve an out-of-band indirect signalling exchange to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. (TO-DO: It is expected that a single abstract algorithm can be identified that supports both the peer-to-peer and client-server connection racing, allowing this text to be merged with conn- establish) 11. </del> RFC-EDITOR: Please remove this section before publication. This document has no actions for IANA. <del> 12. </del> <ins> 11. </ins> <del> 12.1. </del> <ins> 11.1. </ins> Implementations should avoid downgrade attacks that allow network interference to cause the implementation to select less secure, or entirely insecure, combinations of paths and protocols. <del> 12.2. </del> <ins> 11.2. </ins> See fastopen for security considerations around racing with 0-RTT data.

Discussion:
Restructure to address Rearrange to include Rendezvous and Environment Discovery text in connection establishment. Remove that previous section. was intended to check the ordering of sections against the other drafts and to merge . I have merged the Rendezvous text into Connection Establishment, but I haven't changed any of the text yet. I am a little concerned about creating an interdependancy in the text between derriving endpoints (name lookup) and the ICE/TURN stuff. More generally, I am not sure what to say about name resolution and proxies (ala ). TOR opens a can of privacy worms for name lookup and racing paths that I am not sure how to address.
Looks good apart from typo!
Having proxies to go through on a system (SOCKS, HTTP Connect, etc) or a set of TOR endpoints requires the implementation to do some nested/recursive work, and pass down endpoints correctly to protocol instances. The implementation document should describe this.
+1
There is already text in 4.1.3.3. Protocol Options. Is that sufficient or do we need more?
Review structure. What fits in pre-establishment. Relation system policy - cached state. Generalizes
Discussed in Singapore, we'll have more structure comments later, but we've done a lot of changes since then.
I like the change, as it makes the process much clearer and reduces the awkwardness of ICE/STUN. To model TOR, SOCKS, or other tunnelling protocols, I would refrain from seeing them as protocol stacks, but treat them as derived paths that only support these stacks. This removes the need for cupeling name resolution to the protocol stack, and looks quite natural to me as these derived paths may be available in the connection cache or need to be established for name resolution anyway before starting the real candidate racing. If we want to do so, it might be easier to talk about paths (that have one or more corresponding local endpoints), derived paths, derived remote endpoints (as result of name resolution on each path) and protocol stacks.