Change:
4.1.1. <ins> Both Local and Remote Endpoint Candidates must be discovered during connection establishment.  To support ICE, or similar protocols, that involve out-of-band indirect signalling 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. 4.1.1.1. 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. 4.1.1.2. 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. 4.1.2. </ins> When an implementation responsible for connection establishment needs to consider multiple options, it should logically structure these options as a hierarchical tree.  Each leaf node of the tree

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.