Original text:
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_active_migration" </del>  transport parameter in all new QUIC connections.  It SHOULD NOT send NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits <del> set to '11' MUST revert to 5-tuple routing.  These connection IDs may be of any length; however, see cid-entropy for limits on this length. </del>  2.3. receive similar treatment regardless of why they're unroutable: The config rotation bits (config-rotation) may not correspond to <del> an active configuration.  Note: a packet with a DCID that indicates 5-tuple routing (see config-failover) is always routable. </del>  The DCID might not be long enough for the decoder to process. each incoming packet and route that packet accordingly. However, once the routing decision has been made, the load balancer <del> MAY associate the 4-tuple with the decision.  This has two advantages: </del>  <del> The load balancer only extracts the server ID once per incoming 4-tuple.  When the CID is encrypted, this substantially reduces computational load. </del>  Incoming Stateless Reset packets and ICMP messages are easily routed to the correct origin server. exposing information about the target domain to the entire network; or <del> tenants can use 4-tuple routing in their CIDs (in which case they SHOULD disable migration in their connections), which neutralizes the value of QUIC-LB but preserves privacy. </del>  When configuring QUIC-LB, administrators must evaluate the privacy tradeoff considering the relative value of each of these properties,

Reviewer comments:
The '11' codepoint might be better defined. It would be good, for instance, if a stateful load balancer actually stored the observed CID so that the connection can survive a NAT rebinding.
Actually this is a bit harder than we'd like. If the load balancer is stateless, then the short-header processing would have to be based on the destination connection ID to be robust to NAT rebinding. But then, as the connection ID will change mid-handshake, long-header processing needs a different approach. I don't see how, logically, a stateless LB can maintain consistency between these two results unless we force the unconfigured server to retain most of the client-generated CID.
Having reflected on this a bit more, this is what I think we should do: Keep 0b11 as 4-tuple routing. However Load Balancers MAY observe destination connection IDs and keep state on them, to later survive a NAT rebinding. I see two use cases for 0b11: (1) a general purpose server that always uses QUIC-LB, whether or not it's behind an LB, for simplicity. So when it's not behind a Layer 4 LB it just generates random CIDs except for the first byte. As an added bonus, if there is an unknown L4 LB in front of it the behavior will not be pathological, at least until there's a migration. But in general, the rebinding performance is not all that important. (2) As a panic mode when things are misconfigured or the server has run out of nonces. Again, I'm not sure rebinding performance is super-critical. In other words, if a server is behind an L4 load balancer is and is using 0b11, something has gone very wrong.

Revised text:
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 0b11 and SHOULD use the "disable_active_migration" </ins> transport parameter in all new QUIC connections.  It SHOULD NOT send NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits  <ins> set to 0b11 MUST route using an algorithm based solely on the address/port 4-tuple, which is consistent well beyond the QUIC handshake.  However, a load balancer MAY observe the connection IDs used during the handshake and populate a connection ID table that allows the connection to survive a NAT rebinding, and reduces the probability of connection failure due to a change in the number of servers. When using codepoint 0b11, all bytes but the first SHOULD have no larger of a chance of collision as random bytes.  The connection ID SHOULD be of at least length 8 to provide 7 bytes of entropy after the first octet with a low chance of collision.  Furthermore, servers in a pool SHOULD also use a consistent connection ID length to simplify the load balancer's extraction of a connection ID from short headers. </ins> 2.3. receive similar treatment regardless of why they're unroutable: The config rotation bits (config-rotation) may not correspond to  <ins> an active configuration.  Note: a packet with a DCID with config ID codepoint 0b11 (see config-failover) is always routable. </ins> The DCID might not be long enough for the decoder to process. each incoming packet and route that packet accordingly. However, once the routing decision has been made, the load balancer  <ins> MAY associate the 4-tuple or connection ID with the decision.  This has two advantages: </ins>  <ins> The load balancer only extracts the server ID once until the 4-tuple or connection ID changes.  When the CID is encrypted, this might reduce computational load. </ins> Incoming Stateless Reset packets and ICMP messages are easily routed to the correct origin server. exposing information about the target domain to the entire network; or  <ins> tenants can use the 0b11 codepoint in their CIDs (in which case they SHOULD disable migration in their connections), which neutralizes the value of QUIC-LB but preserves privacy. </ins> When configuring QUIC-LB, administrators must evaluate the privacy tradeoff considering the relative value of each of these properties,