Change:
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.

Discussion:
Each Issuance protocol MUST come with a detailed analysis of the privacy impacts of the protocol, why these impacts are justified, and <del> guidelines on changes to the parametrization in parametrization. </del> <ins> guidelines on how to deploy the protocol to minimize any privacy impacts. </ins> Clients obtain the Issuer public key directly from the Origin using the process described in HTTP-Authentication.  Clients MAY apply some

expiration information as metadata alongside the token; See metadata for more discussion about metadata constraints.  Both techniques are equivalent since they cryptographically bind expiration to individual <del> tokens. Key rotations should be limited in frequency for similar reasons. See parametrization for guidelines on what frequency of key rotations are permitted. </del> <ins> tokens.  Key rotations should be limited in frequency for similar reasons. </ins> 3.2.3.

unique issuer public key for each value of metadata, such that N keys yields log2(N) bits of metadata.  The total amount of metadata bits included in a token is the sum of public and private metadata bits. <del> See parametrization for discussion about metadata limits. </del> Public metadata is that which clients can observe as part of the token issuance flow.  Public metadata can either be transparent or

functionalities through new issuance protocols.  Each issuance protocol SHOULD come with a detailed analysis of the privacy impacts of the extension, why these impacts are justified, and guidelines on <del> changes to the parametrization in parametrization.  Any extension to the Privacy Pass protocol MUST adhere to the guidelines specified in issuer-role for managing Issuer public key data. </del> <ins> how to deploy the protocol to minimize any privacy impacts.  Any extension to the Privacy Pass protocol MUST adhere to the guidelines specified in issuer-role for managing Issuer public key data. </ins> 4.

of information that Issuer's may learn about Clients otherwise. Since this metadata may be useful for practical deployments of Privacy Pass, Issuers must balance this against the reduction in <del> Client privacy.  In general, Issuers should permit no more than 32 bits of metadata, as this can uniquely identify each possible user. We discuss this more in parametrization. </del> <ins> Client privacy.  In general, Issuers should bound the metadata permitted so as to not allow it to uniquely identify each possible user. </ins> 5.2.

time, a strict bound SHOULD be applied to the active number of Issuers in the ecosystem.  We propose that allowing no more than 4 Issuers at any one time is highly preferable (leading to a maximum of <del> 64 possible user segregations).  However, as highlighted in parametrization, having a very large user base (> 5 million users), could potentially allow for larger values.  Issuer replacements </del> <ins> 64 possible user segregations).  However, having a very large user base could potentially allow for larger values.  Issuer replacements </ins> should only occur with the same frequency as config rotations as they can lead to similar losses in anonymity if clients still hold redemption tokens for previously active Issuers.

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>