Original text:
There are three different approaches to racing the attempts for different nodes of the connection establishment tree: <del> Immediate </del>  <del> Delayed </del>  Failover Each approach is appropriate in different use-cases and branch types. However, to avoid consuming unnecessary network resources, <del> implementations should not use immediate racing as a default </del>  approach. The timing algorithms for racing should remain independent across 4.2.1. <del> Immediate racing is when multiple alternate branches are started </del>  without waiting for any one branch to make progress before starting the next alternative.  This means the attempts are effectively <del> simultaneous.  Immediate racing should be avoided by implementations, since it consumes extra network resources and establishes state that might not be used. </del>  4.2.2. <del> Delayed racing can be used whenever a single node of the tree has </del>  multiple child nodes.  Based on the order determined when building the tree, the first child node will be initiated immediately, followed by the next child node after some delay.  Once that second initiated, or one of the child nodes successfully completes its negotiation. <del> Delayed racing attempts occur in parallel.  Implementations should </del>  not terminate an earlier child connection attempt upon starting a secondary child.

Reviewer comments:
Opening this to follow up on a comment by NAME on that is now closed. "Simultaneous" and "Staggered" would be better names than "Immediate" and "Delayed". Just from these terms, I would normally think that "Immediate" means to start racing right away, whereas "Delayed" means that nothing would happen for some time. So these two terms are slightly misleading in my opinion.)
I agree this would be an improvement.
LGTM (of course :-) )Thanks, looks good!

Revised text:
There are three different approaches to racing the attempts for different nodes of the connection establishment tree:  <ins> Simultaneous </ins>  <ins> Staggered </ins> Failover Each approach is appropriate in different use-cases and branch types. However, to avoid consuming unnecessary network resources,  <ins> implementations should not use simultaneous racing as a default </ins> approach. The timing algorithms for racing should remain independent across 4.2.1.  <ins> Simultaneous racing is when multiple alternate branches are started </ins> without waiting for any one branch to make progress before starting the next alternative.  This means the attempts are effectively  <ins> simultaneous.  Simultaneous racing should be avoided by implementations, since it consumes extra network resources and establishes state that might not be used. </ins> 4.2.2.  <ins> Staggered racing can be used whenever a single node of the tree has </ins> multiple child nodes.  Based on the order determined when building the tree, the first child node will be initiated immediately, followed by the next child node after some delay.  Once that second initiated, or one of the child nodes successfully completes its negotiation.  <ins> Staggered racing attempts occur in parallel.  Implementations should </ins> not terminate an earlier child connection attempt upon starting a secondary child.