Change:
imposes other operational constraints.  The other requires shared key, but has no such constraints. <del> Retry services MUST forward all non-Initial QUIC packets, as well as Initial packets from the server. </del> <ins> Retry services MUST forward all QUIC packets that are not of type Initial or 0-RTT.  Other packets types might involve changed IP addresses or connection IDs, so it is not practical for Retry Services to identify such packets as valid or invalid. </ins> 5.1. Regardless of mechanism, a retry service has an active mode, where it is generating Retry packets, and an inactive mode, where it is not, based on its assessment of server load and the likelihood an attack <del> is underway.  The choice of mode MAY be made on a per-packet basis, through a stochastic process or based on client address. </del> <ins> is underway.  The choice of mode MAY be made on a per-packet or per- connection basis, through a stochastic process or based on client address. </ins> A retry service MUST forward all packets for a QUIC version it does not understand.  Note that if servers support versions the retry <del> service does not, this may unacceptably increase loads on the servers.  However, dropping these packets would introduce chokepoints to block deployment of new QUIC versions.  Note that future versions of QUIC might not have Retry packets, or require different information. </del> <ins> service does not, this may increase load on the servers.  However, dropping these packets would introduce chokepoints to block deployment of new QUIC versions.  Note that future versions of QUIC might not have Retry packets, require different information in Retry, or use different packet type indicators. </ins> 5.2. The no-shared-state retry service requires no coordination, except <del> that the server must be configured to accept this service.  The scheme uses the first bit of the token to distinguish between tokens from Retry packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint '1'). </del> <ins> that the server must be configured to accept this service and know which QUIC versions the retry service supports.  The scheme uses the first bit of the token to distinguish between tokens from Retry packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint '1'). </ins> 5.2.1. <ins> The configuration agent distributes a list of QUIC versions to be served by the Retry Service. 5.2.2. </ins> A no-shared-state retry service MUST be present on all paths from potential clients to the server.  These paths MUST fail to pass QUIC traffic should the service fail for any reason.  That is, if the

Discussion:
Fixes URL
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni