quicwg
Huge logical leap from opening a new path to PATH_RESPONSE
To open a new path, an endpoint MUST use a new connection ID associated with an unused path ID. When sending a PATH_RESPONSE frame, an endpoint MUST use a connection ID associated to the same path ID as used in the packet that contained the PATH_CHALLENGE frame.
This might be obvious to those of us who understand the chain of logic from "open a new path" to "testing for connectivity and willingness to communicate on that new path" to "sending PATH_CHALLENGE" to "that generating a PATH_RESPONSE". But it is a huge jump for someone less familiar with the protocol.
Yes, we struggled a bit with that one. There is a strong assumption that all path creation will start with an exchange of "path challenge / path response", but that's not actually required, and a few lines after the text that you cite you will find "The server may receive packets for a yet unused path ID that do not contain a PATH_CHALLENGE frame. Such packets are valid if they can be properly decrypted given a valid connection ID."
Maybe we should rewrite the first paragraph as:
To open a new path, an endpoint MUST use a new connection ID associated with an unused path ID. When sending packets on the same path, an endpoint MUST use a connection ID associated to the same path ID as used in the packet received by the server. If an endpoint receives a PATH_CHALLENGE, the PATH_RESPONSE MUST be sent on the same path as the packet that contained the PATH_CHALLENGE frame.
