Change:
4.2. <del> The ECMP CID Algorithm is similar to the plaintext CID algorithm, but allows the L4 load balancer to decide which server to send traffic to on a per-CID basis.  This still links connections to servers, but the connection is dynamic and slightly less linkable than the plaintext CID algorithm.  The format is depicted in the figure below. </del> <ins> The Low-Config CID Algorithm is similar to the plaintext CID algorithm, but allows the load balancer to assign server 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 connections, until the server ID codespace is exhausted. </ins> 4.2.1. <del> The configuration agent selects a length for the server ID encoding. This length MUST have enough entropy to have a different code point for each server. </del> <ins> The configuration agent selects a length for the server ID encoding that MUST have at least enough entropy to have a different code point for each server.  It MUST be no more than seven octets. The configuration agent also selects an LB Timeout. </ins> 4.2.2. <del> On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  If these octets match an existing server ID, the packets are routed to the new server ID.  If the octets are not a match and the packet is an Initial packet, then it is assumed to be a new flow and load balanced. </del> <ins> The load balancer maintains a table of all assigned server IDs, which is initialized empty.  On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  If these octets match an existing server ID, the packets are routed to the matching server ID.  As there are no assigned server IDs at first, the first incoming packet has a non-compliant DCID by definition. The server ID table is distinct for each instance of low-config CID algorithm configuration, even if two configurations use the same server ID length.  Thus a given server ID might correspond to a different server in each configuration. Note that each server will usually have many server IDs assigned to it. The load balancer MUST keep track of the most recent observation of each server ID in the table and delete the entries when the time since that observation exceeds the LB Timeout. 4.2.2.1. In QUIC version 1, incoming Connection IDs generated by clients should be no less than 8 octets, so all non-compliant DCIDs should not be due to insufficient length.  Load balancers that are operating the Low-Config CID algorithm SHOULD drop incoming packets with CIDs too short to execute it unless it can be routed using another configured algorithm. If the DCID is non-compliant solely because the server ID is unassigned, the load balancers follows the procedures in routing- algorithms and adds the server ID and assignment the table. If the DCID references the 4-tuple routing bits or an undefined configuration, use the following procedure to establish a predictable template for server ID extraction: Identify the instance of Low-Config CID configuration with the largest config rotation codepoint.  For example, if configurations 0b10, 0b01, and 0b00 all use the low-config CID algorithm and have server ID lengths of 3, 5, and 7 octets, respectively, and a packet comes in with codepoint 0b11, the load balancer would extract 3 octets for the server ID. Extract the appropriate number of octets. If the server ID matches one already in the table, forward the packet to that server. If not, the load balancer runs the algorithm of its choosing and adds the extracted server ID to the table corresponding to the highest-value Low-Config CID Configuration codepoint. </ins> 4.2.3. <del> The server chooses a connection ID length.  This MUST be at least one byte longer than the routing bytes. </del> <ins> The server chooses how many octets to reserve for its own use, which MUST be at least one octet.  It also maintains a list of server IDs it has observed and the last time it received a packet with that ID. This list is distinct for each instance of Low-Config CID Algorithm configuration. When a server receives a packet, it extracts the server ID.  If the config rotation bits in the CID encode 4-tuple routing or an undefined configuration, it uses the highest-value Low-Config CID config rotation codepoint and extracts the server ID as if that configuration applied. </ins> <del> When a server needs a new connection ID, it selects a random CID from another connection which is known to route identically and randomizes the non-routing bytes of the CID. </del> <ins> If the server ID is not currently in the list, the server adds it. The server ID's entry is also updated with the most recent arrival of that server ID. When a server needs a new connection ID, it uses one of the server IDs in its list to populate the server ID field of that CID.  It SHOULD vary this selection to reduce linkability within a connection. If a server has not received a connection ID encoding a particular server ID within the LB timeout, it MUST retire any outstanding CIDs that use that server ID and cease generating any new ones. A server SHOULD have a mechanism to stop using some server IDs if the list gets large relative to its share of the codepoint space, so that these allocations time out and are freed for reuse by servers that have recently joined the pool. </ins> 4.3.

Discussion:
follow-on to , also fixing
NAME asks if there is added value in expressing server ID lengths in bits instead octets. This is a bit of implementation complexity and a lot of churn in the spec and the handful of implementations that exist, but it does give the configuration agent a little more granularity. Does anyone find the value of this granularity to be compelling?
My thinking is that increasing/decreasing the server ID space by 256 is quite a large jump and could make config rotation a bit more complex. Adding an extra bit to the server ID doubles the number of IDs, which is a fairly widely used increase in data structures and algorithms.
While having such fine control would optimize for efficiency, splitting up bytes like this would complicate implementation. I'm also doubt that 1B of overhead is really going to affect anything. Closing this issue due to old age; can reopen if anyone wants to fight it out.
NAME proposed a PCID design that assigns SIDs on the fly instead of having to pre-configure them. There are drawbacks but it has some nice properties.
This is merged, but I'm going to take the question of what we can do with these dueling plaintext designs to the list.
List discussion was not helpful; closing this with the dynamic method still in the draft.