Change:
This change allows servers to send a preferred address of each address family. The previous definition of preferred_address only allowed sending one address family, and this had the disadvantage of picking the non-deterministic address family used by the Initial if the client is performing Happy Eyeballs. Clients may now use the best address family based on their network attachment.
NAME I went with this approach to minimize changes from the current design. Having a list that allows different ports and future versions of IP are fine by me, but there seemed to be more pushback when that was proposed in . As long as we have a way of communicating one IPv4 address and one IPv6 address I'm happy.
We could allow multiple PreferredAddress TPs and avoid the zero-length address problem.
NAME Thank you for the clarification. I think I'm fine with that. NAME The PreferredAddress structure includes Connection ID and Stateless Reset Token. I think we should avoid requiring the server to send them twice when it is constrained by the 3-packet rule.
I've simplified the wire-format using NAME suggestion with separate port numbers
NAME I think migration and preferred address are separate parts of the protocol. The goal of this PR is to improve preferred address. It allows the client to pick the address family it transfers to right after the handshake. If the server only provides you with a preferred address family you don't have access to, you can simply ignore it - and that's not new from this PR. I've slightly tweaked the text to clarify how clients respond to preferred_address. Does this address your concerns?
I'm good with this PR. NAME -- can you see if your concern is addressed?
NAME is there anything left for me to do so this can get merged in?
You could wait until I had time to check it, that's all.
After reading my text, I am not entirely happy with it, but I lack a better suggestion.Still LG

Discussion:
A server conveys a preferred address by including the preferred_address transport parameter in the TLS handshake. <del> Once the handshake is finished, the client SHOULD initiate path validation (see migrate-validate) of the server's preferred address using the connection ID provided in the preferred_address transport parameter. </del> <ins> Servers MAY communicate a preferred address of each address family (IPv4 and IPv6) to allow clients to pick the one most suited to their network attachment. Once the handshake is finished, the client SHOULD select one of the two server's preferred addresses and initiate path validation (see migrate-validate) of that address using the connection ID provided in the preferred_address transport parameter. </ins> If path validation succeeds, the client SHOULD immediately begin sending all future packets to the new server address using the new

NOT send more than a minimum congestion window's worth of non-probing packets to the new address before path validation is complete. <ins> A client that migrates to a new address SHOULD use a preferred address from the same address family for the server. </ins> 10. Connections should remain open until they become idle for a pre-

The server's preferred address is used to effect a change in server address at the end of the handshake, as described in preferred-address.  The format of this transport parameter is the <del> PreferredAddress struct shown in fig-preffered-address.  This transport parameter is only sent by a server. </del> <ins> PreferredAddress struct shown in fig-preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family. </ins> If present, transport parameters that set initial flow control limits (initial_max_stream_data_bidi_local,