Original text:
These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load <del> balancer.  These are called "non-compliant DCIDs": </del>  The config rotation bits (config-rotation) may not correspond to an active configuration.  Note: a packet with a DCID that Load balancers MUST forward packets with compliant DCIDs to a server in accordance with the chosen routing algorithm. <del> Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. </del>  The routing of long headers with non-compliant DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However, version-invariant properties of QUIC described in QUIC-INVARIANTS to maximize its robustness to future versions of QUIC. <del> An arbitrary algorithmr MUST NOT make the routing behavior dependent </del>  on any bits in the first octet of the QUIC packet header, except the first bit, which indicates a long header.  All other bits are QUIC <del> version-dependent and intermediaries should not base their design on </del>  version-specific templates. For example, one arbitrary algorithm might convert a non-compliant The corresponding server configurations contain one or more unique server IDs. <del> A dynamically allocated configuration does not include any bespoke </del>  assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the 4.3.1. <del> In the manual allocation method, the configuration agent assigns at </del>  least one server ID to each server. When forwarding a packet with a long header and non-compliant DCID, 4.3.2. In the dynamic allocation method, the load balancer assigns server <del> IDs dynamically so that configuration does not require bespoke server ID assignment.  This also reduces linkability.  However, it requires state at the load balancer that roughly scales with the number of </del>  connections, until the server ID codespace is exhausted. 4.3.2.1.

Reviewer comments:
Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.

Revised text:
These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load  <ins> balancer.  Those that are not routable are "non-compliant DCIDs" and receive similar treatment regardless of why they're non-compliant: </ins> The config rotation bits (config-rotation) may not correspond to an active configuration.  Note: a packet with a DCID that Load balancers MUST forward packets with compliant DCIDs to a server in accordance with the chosen routing algorithm.  <ins> Load balancers SHOULD drop short header packets with non-compliant DCIDs. </ins> The routing of long headers with non-compliant DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However, version-invariant properties of QUIC described in QUIC-INVARIANTS to maximize its robustness to future versions of QUIC.  <ins> An arbitrary algorithm MUST NOT make the routing behavior dependent </ins> on any bits in the first octet of the QUIC packet header, except the first bit, which indicates a long header.  All other bits are QUIC  <ins> version-dependent and intermediaries SHOULD NOT base their design on </ins> version-specific templates. For example, one arbitrary algorithm might convert a non-compliant The corresponding server configurations contain one or more unique server IDs.  <ins> A dynamically allocated configuration does not have a pre-defined </ins> assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the 4.3.1.  <ins> In the static allocation method, the configuration agent assigns at </ins> least one server ID to each server. When forwarding a packet with a long header and non-compliant DCID, 4.3.2. In the dynamic allocation method, the load balancer assigns server  <ins> IDs dynamically so that configuration does not require fixed server ID assignment.  This reduces linkability.  However, it requires state at the load balancer that roughly scales with the number of </ins> connections, until the server ID codespace is exhausted. 4.3.2.1.