Draft: draft-ietf-taps-impl

Commentary: 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   , 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 !
Paragraph (version A):
Connection establishment is divided into two top-level steps:
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.
Paragraph (version A):
For ease of illustration, this document structures the candidates for
racing as a tree.  This is not meant to restrict implementations from
structuring racing candidates differently.
Paragraph (version B):
Connection establishment is divided into two top-level steps:
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.
Paragraph (version B):
For ease of illustration, this document structures the candidates for
racing as a tree (see tree-structure).  This is not meant to restrict
implementations from structuring racing candidates differently.
Paragraph (version A):
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.
Paragraph (version B):
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.