Original text:
7. <del> 7.1. </del>  <del> Note: This algorithm does not take the off-path scenario into account. </del>  <del> The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </del>  The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the value in a "return_routability_check" message of type "path_response". <del> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it updates the peer address binding. If T expires, or the address confirmation fails, the peer address binding is not updated. </del>  <del> After this point, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.2. <del> Note: This algorithm also takes the off-path scenario into account. The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </del> The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the message. corresponds to the old path.  Additionally, a timer T, see timer- choice, is started. <del> The peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on the preference of the path through which the message was received: </del>  If the path through which the message was received is preferred, a "return_routability_check" message of type was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. <del> If T expires, or the address confirmation fails, the peer address binding is not updated.  In this case, the initiator MUST perform a return routability check on the observed new address, as described in regular. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.3.

Reviewer comments:
factor out common text remove the spurious "address confirmation failure": path validation only fails on timeout provide further rationale for choosing between basic and enhanced
We probably need to tell implementers why/when they should choose the basic algorithm vs the enhanced. For example, avoid enhanced if: you need to minimise implementation complexity you have privacy concerns -- i.e., to avoid providing a clear correlation signal off-path attackers are not in your threat model and/or you want to reduce the time it takes to switch path
In the path validation algorithm (both base and enhanced) we say "[...] or the address confirmation fails [...]", but we don't say precisely what we mean by that. If it refers to failure in validating the received Cookie value, than there's a potential out-of-sync with the requirement: "[...] the initiator MUST silently discard any invalid path_response it receives." If not, we should say what we mean by "address confirmation failure."

Revised text:
7.  <ins> The receiver that observes the peer's address or port update MUST stop sending any buffered application data, or limit the data sent to the unvalidated address to the anti-amplification limit. </ins>  <ins> It then initiates the return routability check that proceeds as described either in enhanced or regular, depending on whether the off-path attacker scenario described in off-path is to be taken into account or not. </ins>  <ins> (The decision on what strategy to choose depends mainly on the threat model, but may also be influenced by other considerations.  Examples of impacting factors include: the need to minimise implementation complexity, privacy concerns, the need to reduce the time it takes to switch path.  The choice may be offered as a configuration option to the user.) After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. 7.1. </ins> The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the value in a "return_routability_check" message of type "path_response".  <ins> When the initiator receives the "return_routability_check" message and verifies that it contains the sent cookie, it updates the peer address binding. </ins>  <ins> If T expires the peer address binding is not updated. </ins> 7.2.  The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the message. corresponds to the old path.  Additionally, a timer T, see timer- choice, is started.  <ins> If the path is still functional, the peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on whether the path through which the message was received is the preferred one or not anymore: </ins> If the path through which the message was received is preferred, a "return_routability_check" message of type was received, the initiator MUST perform a return routability check on the observed new address, as described in regular.  <ins> If T expires the peer address binding is not updated.  In this case, the initiator MUST perform a return routability check on the observed new address, as described in regular. </ins> 7.3.