Code change:
While we allow the consumer to start using new CIDs anytime, there are consequences of consuming them excessively, as discussed in starting from this comment. The text clarifies that excessive consumption is not what the issuer needs to support.
NAME For HTTP3, it is natural to assume that the connections would not survive for very long time. In such case, capping the number of total connection IDs is a practical countermeasure against excessive issuance of CIDs. Implementations need not to be as complicated as capping the frequency.
I don't want to put this in the draft. It tells endpoints not to change connection IDs based on some unspecified (scary!) constraints that may or may not be present in a peer. I realize that there might be a limited supply in some implementations, but artificial constraints on the rate of use is not the way I would address the problem. Refusing or slowing issuance of new connection IDs if someone retires too many is a better approach. In other words, implementations should deal with this on their own.
NAME If that's the concern, do you think clarifying that the issue can "refuse or slow issuance of new connection IDs" in section 5.1.1 would be fine? The problem I have with current text is that section 5.1.1 only says that the issuer SHOULD issue new CIDs as the consumer retires them. I think we need to clarify that doing that without limitation could be dangerous.
NAME Moved the clarification to the issuer side. PTAL.
One low-level observation: CID's need to be looked up in a hash table or similar. For a busy server multiplexing many connections, it want this table in fast cache, also to reject invalid CID's fast. You may be able to handle 5000 connections efficiently, but if you are required to handle 8x5000 this can degrade performance, especially on rejection. You can counter this by cryptographically mapping multiple CID's a single internal CID but that is not the simplest approach. Therefore, choosing a minimum number of CID's should be done with care. Would 2 or 3 not be sufficient for most use cases?
NAME > Unfortunately, this is a design change, and a new one. just to be clear, are you referring to my comment on a limit of eight, or something earlier?
NAME I think we should have a separate discussion around a sensible default. Part of the idea here was to make sure that we were very unlikely to run out, even around lost/retransmitted packets on different paths. Choosing a very low number brings with it other potential issues which probably should hold up this change?
NAME yes, I realised this relates to maxconnectionids.
I'm going with editorial then.
While I can see why you'd limit the frequency of issuing new connection IDs, I don't think you should limit the number of total connection IDs per connection.Unfortunately, this is a design change, and a new one. From an abundance of caution, we'll need an issue for this, and chair assessment of consensus.I'm not convinced this is a design change -- there was previously a SHOULD, and this adds additional text (including a MAY) around when you might choose to violate the SHOULD. However, no mandatory behavior is added, changed, or removed.A few nits, but this looks good to me. That said, this issue will need consensus.

Related discussion:
text: available and unused connection IDs.  While each endpoint independently chooses how many connection IDs to issue, endpoints SHOULD provide and maintain at least eight connection IDs.  The <del> endpoint SHOULD do this by always supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  Endpoints that initiate migration and require non-zero-length connection IDs SHOULD provide their peers with new connection IDs before migration, or risk the peer closing the connection. </del> <ins> endpoint SHOULD do this by supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  However, it MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs (see reset-token). An endpoint that initiates migration and requires non-zero-length connection IDs SHOULD ensure that the pool of connection IDs available to its peer allows the peer to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted. </ins> 5.1.2.