Change:
Raising this issue as part of my review of the the Implementation Draft. To a reader who understands "protocol racing" in the "Happy Eyeballs" sense of near-simultaneous connection establishment attempts, parts of Section 4.1 are confusing. It appears as if "real racing" actually only occurs between Derived Endpoints and not e.g., among Alternate Paths, where we instead have "failover after timeout": Section 4.1.1.2 However, in Section 4.1.1.3 "Protocol Options", the "rank[ing] and attempt[ing]" of options is also referred to as "racing": It seems clear that this kind of information is only useful when connection attempts are not in fact "raced" (nearly) in parallel, but are only conducted in succession, where it makes sense to rank the candidates accordingly. This confusion is only cleared up in Section 4.3, where it says: So it appears as if (in partial departure from the Happy Eyeballs RFC) the term "racing" here is meant to include staggered or failover scenarios, somewhat undermining the original metaphor. Suggestions: Explain the extended scope of the "racing" term earlier Perhaps replace some uses the term "racing" with "failover" or even just "ranking"
Mention that "staggered" is the most common form of racing The main thing with racing is that the first one to succeed wins We should add forward references to sections here: We should also explain in this paragraph that the "Staggered" approach is generally the default for racing, and the first one to finish wins.
LGTM, thanks!

Discussion:
application's data. Connection establishment is divided into two top-level steps: <del> Candidate Gathering, to identify the paths, protocols, and endpoints to use, and Candidate Racing (see Section 4.2.2 of I-D.ietf-taps- arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use. </del> <ins> Candidate Gathering (defined in Section 4.2.1 of I-D.ietf-taps-arch), to identify the paths, protocols, and endpoints to use (see gathering); and Candidate Racing (defined in Section 4.2.2 of I- D.ietf-taps-arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use (see racing).  Candidate Racing involves attempting multiple options for connection establishment, and choosing the first option to succeed as the Protocol Stack to use for the connection.  These attempts are usually staggered, starting each next option after a delay, but they can also be performed in parallel or only after waiting for failures. </ins> For ease of illustration, this document structures the candidates for <del> racing as a tree.  This is not meant to restrict implementations from structuring racing candidates differently. </del> <ins> racing as a tree (see tree-structure).  This is not meant to restrict implementations from structuring racing candidates differently. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,

section is the algorithm defining which of these options to try, when, and in what order. <del> During Candidate Gathering, an implementation prunes and sorts branches according to the Selection Property preferences (Section 6.2 of I-D.ietf-taps-interface.  It first excludes all protocols and paths that match a Prohibit property or do not match all Require properties.  Then it will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </del> <ins> During Candidate Gathering (gathering), an implementation prunes and sorts branches according to the Selection Property preferences (Section 6.2 of I-D.ietf-taps-interface.  It first excludes all protocols and paths that match a Prohibit property or do not match all Require properties.  Then it will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </ins> 4.1.