Draft: draft-ietf-quic-transport

Commentary: Section 9.3 of Transport ( ) says : " If the recipient permits the migration , it MUST send subsequent packets to the new peer address and MUST initiate path validation ( Section 8.2 ) to verify the peer 's ownership of the address if validation is not already underway . " In section 9.5 ( ) " Similarly , an endpoint MUST NOT reuse a connection ID when sending to more than one destination address . Due to network changes outside the control of its peer , an endpoint might receive packets from a new source address with the same destination connection ID , in which case it MAY continue to use the current connection ID with the new remote address while still sending from the same local address . " So as long as it 's an unintentional change , everything is clear . But if the destination address changes and the incoming CID changes , but the sender(ie : server ) does n't have any more CIDs , it 's not clear what should be done , as the two MUSTs seem to contradict one another . Or maybe they imply the server ca n't send anything ? 
 Later in 9.5 , there 's also this text that is relevant , but I do n't think it clarifies how to resolve the MUSTs . " An endpoint that exhausts available connection IDs can not probe new paths or initiate migration , nor can it respond to probes or attempts by its peer to migrate . To ensure that migration is possible and packets sent on different paths can not be correlated , endpoints SHOULD provide new connection IDs before peers migrate ; see Section 5.1.1 . If a peer might have exhausted available connection IDs , a migrating endpoint could include a NEWCONNECTIONID frame in all packets sent on a new network path . " 
 So the second quotation has that clarification ( with emphasis ): Is n't this all coherent ? 
 Yes , that clarifies the issue when the CID does not change . But that does not clarify the case when the CID does change and the responder has no more CIDs . 
 Is n't that addressed by this : ? 
 So the answer is : 1 ) It ca n't send anything 2 ) It can send on the old path , but not the new one 
 It can probe the old path - but that is all it can do . 
 Why would it probe the old path that it 's already validated ? 
 I did n't say that it was useful , just possible :) 
 I do n't see a pressing reason to do anything about this . That said , it 's an unfortunate edge case , perhaps we could call it out explicitly , mentioning that this should n't arise if the other parts of the migration machinery are followed ? 
 To be clear , I 'm not looking for a fix as much as clarity on what is supposed to occur . I 'll write a PR that I think will clarify it some and call out the edge case . 
 I 'd argue this is really a MUST unless case , but people tend not to like those , so I tried to stick to the facts in my PR . 
 WFM
Paragraph (version A):
If the recipient permits the migration, it MUST send subsequent
packets to the new peer address and MUST initiate path validation
(migrate-validate) to verify the peer's ownership of the address if
validation is not already underway.
Paragraph (version B):
If the recipient permits the migration, it MUST send subsequent
packets to the new peer address and MUST initiate path validation
(migrate-validate) to verify the peer's ownership of the address if
validation is not already underway.  If the recipient has no unused
connection IDs from the peer, it will not be able to send anything on
the new path until the peer provides one; see migration-linkability.