Code change:
4.2. <del> The Obfuscated CID Algorithm makes an attempt to obscure the mapping of connections to servers to reduce linkability, while not requiring true encryption and decryption.  The format is depicted in the figure </del> <ins> The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID.  The CID format is depicted </ins> below. 4.2.1. <del> The configuration agent selects an arbitrary set of bits of the server connection ID that it will use to route to a given server, called the "routing bits".  The number of bits MUST have enough entropy to have a different code point for each server, and SHOULD have enough entropy so that there are many codepoints for each server. The configuration agent MUST NOT select a routing mask with more than 136 routing bits set to 1, which allows for the first octet and up to 2 octets for server purposes in a maximum-length connection ID. The configuration agent selects a divisor that MUST be larger than the number of servers.  It SHOULD be large enough to accommodate reasonable increases in the number of servers.  The divisor MUST be an odd integer so certain addition operations do not always produce an even number. The configuration agent also assigns each server a "modulus", an integer between 0 and the divisor minus 1.  These MUST be unique for each server, and SHOULD be distributed across the entire number space between zero and the divisor. 4.2.2. Upon receipt of a QUIC packet, the load balancer extracts the selected bits of the Server CID and expresses them as an unsigned integer of that length.  The load balancer then divides the result by the chosen divisor.  The modulus of this operation maps to the modulus for the destination server. Note that any Server CID that contains a server's modulus, plus an arbitrary integer multiple of the divisor, in the routing bits is routable to that server regardless of the contents of the non-routing bits.  Outside observers that do not know the divisor or the routing bits will therefore have difficulty identifying that two Server CIDs route to the same server. Note also that not all Connection IDs are necessarily routable, as the computed modulus may not match one assigned to any server.  These DCIDs are non-compliant as described above. 4.2.3. The server chooses a connection ID length.  This MUST contain all of the routing bits and MUST be at least 9 octets to provide adequate entropy. When a server needs a new connection ID, it adds an arbitrary nonnegative integer multiple of the divisor to its modulus, without exceeding the maximum integer value implied by the number of routing bits.  The choice of multiple should appear random within these constraints. The server encodes the result in the routing bits.  It MAY put any other value into bits that used neither for routing nor config rotation.  These bits SHOULD appear random to observers. 4.3. The Stream Cipher CID algorithm provides true cryptographic protection, rather than mere obfuscation, at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID.  The CID format is depicted below. 4.3.1. </del> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers.

Related discussion:
text: by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.