Code change:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

Related discussion:
text: A server encodes one of its assigned server IDs in any CID it generates using the relevant configuration. <del> 4.3.1. In the static allocation method, the configuration agent assigns at least one server ID to each server. When forwarding a packet with a long header and unroutable DCID, load balancers MUST forward packets with long headers and unroutable DCIDs using an fallback algorithm as specified in fallback-algorithm. 4.3.2. In the dynamic allocation method, the load balancer assigns server IDs dynamically so that configuration does not require fixed server ID assignment.  This reduces linkability and simplifies configuration.  However, it also limits the length of the server ID and requires the load balancer to lie on the path of outbound packets.  As the server mapping is no longer part of the configuration, standby load balancers need an out-of-band mechanism to synchronize server ID allocations in the event of failures of the primary device. To summarize, the load balancer forwards incoming Initial packets arbitrarily and both load balancer and server are sometimes able to infer a potential server ID allocation from the CID in the packet. The server can signal acceptance of that allocation by using it immediately, in which case both entities add it to their permanent table.  Usually, however, the server will reject the allocation by not using it, in which case it is not added to the permanent assignment list. 4.3.2.1. The configuration agent does not assign server IDs, but does configure a server ID length.  The server ID MUST be at least one and no more than seven octets.  See sid-limits for other considerations if also using the Plaintext CID algorithm. 4.3.2.2. The load balancer maintains a mapping of assigned server IDs to routing information for servers, initialized as empty.  This mapping is independent for each operating configuration. Note that when the load balancer's tables for a configuration are empty, all incoming DCIDs corresponding to that configuration are unroutable by definition. The load balancer processes a long header packet as follows: If the config rotation bits do not match a known configuration, the load balancer routes the packet using a fallback algorithm (see fallback-algorithm).  It does not extract a server ID. If there is a matching configuration, but the CID is not long enough to apply the algorithm, the load balancer pads the connection ID with zeros to the required length. Otherwise, the load balancer extracts the server ID in accordance with the configured algorithm and parameters. If the load balancer extracted a server ID already in its mapping, it routes the packet accordingly.  If the server ID is not in the mapping, it routes the packet according to a fallback algorithm and awaits the first long header the server sends in response. If the load balancer extracted an unassigned server ID and observes that the first long header packet the server sends has a Source Connection ID that encodes the same server ID, it adds that server ID to the mapping.  Otherwise, it takes no action. 4.3.2.3. Each server maintains a list of server IDs assigned to it, initialized empty. Upon receipt of a packet with a client-generated DCID, the server MUST follow these steps in order: If the config rotation bits do not correspond to a known configuration, do not attempt to extract a server ID. If the DCID is not long enough to decode using the configured algorithm, pad it with zeros to the required length and extract a server ID. If the DCID is long enough to decode, extract the server ID. If the server ID is not already in its list, the server MUST decide whether or not to immediately use it to encode a CID on the new connection.  If it chooses to use it, it adds the server ID to its list.  If it does not, it MUST NOT use the server ID in future CIDs. The server SHOULD NOT use more than one CID, unless it is close to exhausting the nonces for an existing assignment.  Note also that the load balancer may observe a single entity claiming multiple server IDs because that entity actually represents multiple servers devices or processors. The server MUST generate a new connection ID if the client-generated CID is of insufficient length for the configuration. The server then processes the packet normally. 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 MAY vary this selection to reduce linkability within a connection. After loading a new configuration, a server may not have any available SIDs.  This is because an incoming packet may not contain the config rotation bits necessary to extract a server ID in accordance with the algorithm above.  When required to generate a CID under these conditions, the server MUST generate CIDs using the 5-tuple routing codepoint (see config-failover.  Note that these connections will not be robust to client address changes while they use this connection ID.  For this reason, a server SHOULD retire these connection IDs and replace them with routable ones once it receives a client-generated CID that allows it to acquire a server ID.  As, statistically, one in every four such CIDs can provide a server ID, this is typically a short interval. </del> 4.4. All connection IDs use the following format: