Draft: draft-ietf-quic-transport

Commentary: Reading over the text in the sections commented on , it feels like the heart of the conflict is this : Some sections say that servers do n't migrate in this version of QUIC . This section speaks generically about what an implementation MUST do if the peer migrates , suggesting clients have to obey them if the server does migrate . Additionally , we 've discussed mitigations to other issues ( e.g. ) in which a server might consider certain probes / migrations unacceptable and simply not respond to them . That possibility is n't currently discussed in the text . The solution to both appears to be the same : Condition the MUST on acceptance of the migration . If the migration is somehow unacceptable ( the remote address violates some deployment - specific rule , or the migration is prohibited by this version of QUIC ) these requirements simply do n't attach . The recipient does n't change where they 're sending packets or validate the new address . That might mean the connection fails rather than migrating , but that 's the price you pay . I think this is editorial , because it acknowledges a carve - out in the MUST that we 've always implicitly used to accommodate other text in the doc . 
 6 says : for future work . If a client receives packets from a new server address not indicated by the preferred_address transport parameter , the client SHOULD discard these packets . However , this is after several sections which describe how connection migration works generically from either side , including this text in 9.3 . frame indicates that the peer has migrated to that address . In response to such a packet , an endpoint MUST start sending subsequent packets to the new peer address and MUST initiate path validation ( Section 8.2 ) to verify the peer 's ownership of the unvalidated address . Which is confusing and in fact arguably contradictory . I would propose that we add a sentence to the top of 9.3 that explains that while the text is generic , it actually only applies to servers . 
 Is this enough ? This appears in ( that 's paragraph 6 , not sub - section 6 in case you look at the URL ) . 
 It 's not awesome because it basically contradicts the generic text in 9.3 . But maybe we 're past the point of diminishing returns 
 The intent was to keep the path validation mechanisms generic so that an extension could potentially introduce server migration later . It 's stated in 9.6 and the top of 9 ; before and after the generic part seems sufficient to me . That said , I think the server migration extension would still require that the client be the one to actually make the change . Only clients should ever spontaneously send from a new address . ( P2P scenarios notwithstanding .... ) 
 do I read your last comment as you being OK with closing this with no action ? 
 To be honest , I still think this could use some work , but I 'm willing to let it drop . 
 Thanks . Let 's see if someone has energy / interest to do a PR during the next few days . 
 LGTM , but one nit . I 'd like to review this too .
Paragraph (version A):
An endpoint only changes the address that it sends packets to in
response to the highest-numbered non-probing packet.  This ensures
that an endpoint does not send packets to an old peer address in the
case that it receives reordered packets.
Paragraph (version A):
In response to such a packet, an endpoint 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.
Paragraph (version B):
An endpoint only changes the address to which it sends packets in
response to the highest-numbered non-probing packet.  This ensures
that an endpoint does not send packets to an old peer address in the
case that it receives reordered packets.