Change:
Origin requests an excess of tokens, the Client could choose to not present any tokens for verification if a redemption had already occurred in a given time window. <del> 7. This section provides a summary of the parameters used in the Privacy Pass protocol ecosystem.  These parameters are informed by both privacy and security considerations that are highlighted in privacy and security, respectively.  These parameters are intended as a single reference point for those implementing the protocol. Firstly, let U be the total number of Clients (or users), I be the total number of Issuers.  We let M be the total number of metadata bits that are allowed to be added by any given Issuer.  Assuming that each user accept tokens from a uniform sampling of all the possible Issuers, as a worst-case analysis, this segregates Clients into a total of 2^I buckets.  As such, we see an exponential reduction in the size of the anonymity set for any given user.  This allows us to specify the privacy constraints of the protocol below, relative to the setting of A. 7.1. We make the following assumptions in these parameter choices. Inferring the identity of a user in a 5000-strong anonymity set is difficult. After 2 weeks, all Clients in a system will have rotated to the new key. In terms of additional metadata, the only concrete applications of Privacy Pass that use additional metadata require just a single bit. Therefore, we set the ceiling of permitted metadata to 1 bit for now, this may be revisited in future revisions. The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A. This is derived from the fact that permitting I Issuers lead to 2^I segregations of the total user-base U.  Moreover, if we permit M = 1, then this effectively halves the anonymity set for each Issuer, and thus we incur a factor of 2I in the exponent.  By reducing I, we limit the possibility of performing the attacks mentioned in privacy. We must also account for each user holding issued data for more then one possible active keys.  While this may also be a vector for monitoring the access patterns of Clients, it is likely to unavoidable that Clients hold valid issuance data for the previous key epoch.  This also means that the Issuer can continue to verify redemption data for a previously used key.  This makes the rotation period much smoother for Clients. For privacy reasons, it is recommended that key epochs are chosen that limit Clients to holding issuance data for a maximum of two keys.  By choosing F = L/2 then the minimum value of F is a week, since the minimum recommended value of L is 2 weeks.  Therefore, by the initial assumption, then all users should only have access to only two keys at any given time.  This reduces the anonymity set by another half at most. Finally, the minimum security parameter size is related to the cryptographic security offered by the protocol that is run.  This parameter corresponds to the number of operations that any adversary has in breaking one of the security guarantees in the Privacy Pass protocol I-D.ietf-privacypass-protocol. 7.2. Using the specification above, we can give some example parameterizations.  For example, the current Privacy Pass browser extension PPEXT has nearly 300000 active users (from Chrome and Firefox).  As a result, log_2(U/A) is approximately 6 and so the maximum value of I should be 3. If the value of U is much bigger (e.g. 5 million) then this would permit I = (log_2(5000000/5000)-1)/2 ~= 4 Issuers. 7.3. Using the recommendations in more-servers, it is possible to tolerate larger number of Issuers if Clients in the ecosystem ensure that they only store tokens for a small number of them.  In particular, if Clients limit their storage of redemption tokens to the bound implied by I, then prevents a malicious verifier from triggering redemptions for all Issuers in the ecosystem. </del>

Discussion:
After quickly skimming the parameterization section, it became clear that we already discuss these things in various consideration sections throughout the document, so this was just redundant. Moreover, it's very use-case and deployment specific that once had value in the joint deployment model, so it doesn't seem like particularly helpful now that we've generalized things a bit. Removing and avoiding confusion seems like the best path forward.
I'll take this one to the list before merging.
The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count. If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).
On reflection, we may be better off deleting the text entirely and making sure the justification for the parameterization is adequately covered in the security and privacy considerations elsewhere in the document.