Original text:
3.1. <del> The first two bits of any connection-ID MUST encode the configuration phase of that ID.  QUIC-LB messages indicate the phase of the algorithm and parameters that they encode. A new configuration may change one or more parameters of the old configuration, or change the algorithm used. It is possible for servers to have mutually exclusive sets of supported algorithms, or for a transition from one algorithm to another to result in Fail Payloads.  The four states encoded in these two bits allow two mutually exclusive server pools to coexist, and for each of them to transition to a new set of parameters. </del>  When new configuration is distributed to servers, there will be a transition period when connection IDs reflecting old and new balancers to apply the correct routing algorithm and parameters to incoming packets. <del> Configuration Agents SHOULD make an effort to deliver new configurations to load balancers before doing so to servers, so that load balancers are ready to process CIDs using the new parameters when they arrive. </del>  A Configuration Agent SHOULD NOT use a codepoint to represent a new configuration until it takes precautions to make sure that all Servers MUST NOT generate new connection IDs using an old configuration after receiving a new one from the configuration agent. <del> Servers MUST send NEW_CONNECTION_ID frames that provide CIDS using </del>  the new configuration, and retire CIDs using the old configuration using the "Retire Prior To" field of that frame.  3.2. If a server has not received a valid QUIC-LB configuration, and believes that low-state, Connection-ID aware load balancers are in the path, it SHOULD generate connection IDs with the config rotation <del> bits set to '11' and SHOULD use the "disable_migration" transport parameter in all new QUIC connections.  It SHOULD NOT send </del>  NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits A server not using this functionality SHOULD make the six bits appear to be random.  4. In QUIC-LB, load balancers do not generate individual connection IDs 10.3.  A simple deployment of QUIC-LB in a cloud provider might use the same global QUIC-LB configuration across all its load balancers that route to customer servers.  An attacker could then simply become a masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits <del> (config-rotation).  Note that either of these techniques exposes information to outside observers, as traffic destined for each server set can be easily distinguished. </del>  These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. <del> 10.4. </del>  Section 21.9 of QUIC-TRANSPORT discusses the Stateless Reset Oracle attack.  For a server deployment to be vulnerable, an attacking

Reviewer comments:
Erik Fuller points out via email: He's right. We should just call it a configuration ID and be clearer on what's what.

Revised text:
3.1.  <ins> The first two bits of any connection ID MUST encode an identifier for the configuration that the connection ID uses.  This enables incremental deployment of new QUIC-LB settings (e.g., keys). </ins> When new configuration is distributed to servers, there will be a transition period when connection IDs reflecting old and new balancers to apply the correct routing algorithm and parameters to incoming packets.  <ins> Configuration Agents SHOULD deliver new configurations to load balancers before doing so to servers, so that load balancers are ready to process CIDs using the new parameters when they arrive. </ins> A Configuration Agent SHOULD NOT use a codepoint to represent a new configuration until it takes precautions to make sure that all Servers MUST NOT generate new connection IDs using an old configuration after receiving a new one from the configuration agent.  <ins> Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using </ins> the new configuration, and retire CIDs using the old configuration using the "Retire Prior To" field of that frame. <ins> It also possible to use these bits for more long-lived distinction of different configurations, but this has privacy implications (see multiple-configs). </ins> 3.2. If a server has not received a valid QUIC-LB configuration, and believes that low-state, Connection-ID aware load balancers are in the path, it SHOULD generate connection IDs with the config rotation  <ins> bits set to '11' and SHOULD use the "disable_active_migration" transport parameter in all new QUIC connections.  It SHOULD NOT send </ins> NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits A server not using this functionality SHOULD make the six bits appear to be random. <ins> 3.4. The first octet has the following fields: CR: Config Rotation bits. CID Len: Length Self-Description (if applicable).  Encodes the length of the Connection ID following the First Octet. </ins> 4. In QUIC-LB, load balancers do not generate individual connection IDs 10.3. <ins> During the period in which there are multiple deployed configuration IDs (see config-rotation), there is a slight increase in linkability. The server space is effectively divided into segments with CIDs that have different config rotation bits.  Entities that manage servers SHOULD strive to minimize these periods by quickly deploying new configurations across the server pool. 10.4. </ins> A simple deployment of QUIC-LB in a cloud provider might use the same global QUIC-LB configuration across all its load balancers that route to customer servers.  An attacker could then simply become a masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits  <ins> (config-rotation).  Note that either solution has a privay impact; see multiple-configs. </ins> These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID.  <ins> 10.5. </ins> Section 21.9 of QUIC-TRANSPORT discusses the Stateless Reset Oracle attack.  For a server deployment to be vulnerable, an attacking