Draft: draft-ietf-quic-transport

Commentary: The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE . We removed that long ago , but the text retained echoes of that choice . 
 Currently , does not specify which path a PATHRESPONSE needs to be sent over . That was somewhat surprising to me , as I had expected it to be scoped to the path that PATHCHALLENGE was received on . If it is n't , could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path ( and ideally explaining why it is n't ) ? 
 So I thought we were really crisp about this , but we were not . PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received . We 're clear about this when it comes to preferred address handling , but there is some vestigial text that contradicts this . That should be fixed . 
 For the record , I personally believe that adequately resolves this issue while remaining purely editorial . 
 Thanks for being so prompt  . I will leave this for a bit to allow others a chance to spot errors , but I plan to merge this before we publish -30 ( real soon now , I hope ) . 
 Yes , the requirement was removed but the inverse statement was never explicitly . corrects that . 
 Thanks for writing this up , tiny wording suggestions , but looking great ! Thanks for writing this up , I think this adequately resolves my concerns from .
Paragraph (version A):
Path validation tests that packets can be both sent to
(PATH_CHALLENGE) and received from (PATH_RESPONSE) a peer on the
path.  Importantly, it validates that the packets received from the
migrating endpoint do not carry a spoofed source address.
Paragraph (version B):
Path validation tests that packets sent on a path to a peer are
received by that peer.  Path validation is used to ensure that
packets received from a migrating peer do not carry a spoofed source
address.
Paragraph (version B):
Path validation does not validate that a peer can send in the return
direction.  The peer performs independent validation of the return
path.
Paragraph (version A):
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
containing a random payload on the path to be validated.
Paragraph (version B):
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
containing an unpredictable payload on the path to be validated.
Paragraph (version A):
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by
echoing the data contained in the PATH_CHALLENGE frame in a
PATH_RESPONSE frame.  An endpoint MUST NOT delay transmission of a
packet containing a PATH_RESPONSE frame unless constrained by
congestion control.
Paragraph (version B):
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by
echoing the data contained in the PATH_CHALLENGE frame in a
PATH_RESPONSE frame.  A PATH_RESPONSE frame does not need to be sent
on the network path where the PATH_CHALLENGE was received; a
PATH_RESPONSE can be sent on any network path.  An endpoint MUST NOT
delay transmission of a packet containing a PATH_RESPONSE frame
unless constrained by congestion control.
Paragraph (version A):
A new address is considered valid when a PATH_RESPONSE frame is
received that contains the data that was sent in a previous
PATH_CHALLENGE frame.  Receipt of an acknowledgment for a packet
containing a PATH_CHALLENGE frame is not adequate validation, since
the acknowledgment can be spoofed by a malicious peer.
Paragraph (version B):
Path validation succeeds when a PATH_RESPONSE frame is received that
contains the data that was sent in a previous PATH_CHALLENGE frame.
This validates the path on which the PATH_CHALLENGE was sent.
Paragraph (version B):
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE
frame is not adequate validation, since the acknowledgment can be
spoofed by a malicious peer.