Change:
Hopefully this will close the gap between what we want Retry Services to do and reality.
It would help the anti-DDoS properties if the Retry Service could receive explicit instructions about which QUIC versions the server might support. This provides a way to deploy new versions without having to upgrade the retry service software or hardware.

Discussion:
connection basis, through a stochastic process or based on client address. <ins> A configuration agent MUST distribute a list of QUIC versions the Retry Service supports.  It MAY also distribute either an "Allow- List" or a "Deny-List" of other QUIC versions.  It MUST NOT distribute both an Allow-List and a Deny-List. The Allow-List or Deny-List MUST NOT include any versions included for Retry Service Support. The Configuration Agent MUST provide a means for the entity that controls the Retry Service to report its supported version(s) to the configuration Agent.  If the entity has not reported this information, it MUST NOT activate the Retry Service and the configuration agent MUST NOT distribute configuration that activates it. The configuration agent MAY delete versions from the final supported version list if policy does not require the Retry Service to operate on those versions. The configuration Agent MUST provide a means for the entities that control servers behind the Retry Service to report either an Allow- List or a Deny-List. If all entities supply Allow-Lists, the consolidated list MUST be the union of these sets.  If all entities supply Deny-Lists, the consolidated list MUST be the intersection of these sets. If entities provide a mixture of Allow-Lists and Deny-Lists, the consolidated list MUST be a Deny-List that is the intersection of all provided Deny-Lists and the inverses of all Allow-Lists. If no entities that control servers have reported Allow-Lists or Deny-Lists, the default is a Deny-List with the null set (i.e., all unsupported versions will be admitted).  This preserves the future extensibilty of QUIC. </ins> A retry service MUST forward all packets for a QUIC version it does <del> not understand.  Note that if servers support versions the retry 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. </del> <ins> not support that are not on a Deny-List or absent from an Allow-List. Note that if servers support versions the retry service does not, this may increase load on the servers. Note that future versions of QUIC might not have Retry packets, require different information in Retry, or use different packet type indicators. </ins> 6.2.

6.2.1. <del> The configuration agent distributes a list of QUIC versions to be served by the Retry Service. </del> <ins> See common-requirements. </ins> 6.2.2.

6.3.2. The configuration agent generates and distributes a "token key", a <del> "token IV", a key sequence, and a list of QUIC versions the service supports.  It must also inform the service if a NAT lies between the service and the servers. </del> <ins> "token IV", a key sequence, and the information described in common- requirements. </ins> 6.3.3.

server also must have the token key. A non-shared-state Retry Service need only be configured with the <del> QUIC versions it supports.  A shared-state Retry Service also needs the token key, and to be aware if a NAT sits between it and the servers. </del> <ins> QUIC versions it supports, and an Allow- or Deny-List.  A shared- state Retry Service also needs the token key, and to be aware if a NAT sits between it and the servers. </ins> The following pseudocode describes the data items necessary to store a full QUIC-LB configuration at the server.  It is meant to describe