Change:
maximum value of I should be 3. If the value of U is much bigger (e.g. 5 million) then this would <del> permit I = (log_2(5000000/5000)-1)/2 ~= 4 servers. </del> <ins> permit I = (log_2(5000000/5000)-1)/2 ~= 4 Issuers. </ins> <del> 10.3. </del> <ins> 6.3. </ins> Using the recommendations in more-servers, it is possible to tolerate <del> larger number of servers if clients in the ecosystem ensure that they </del> <ins> larger number of Issuers if Clients in the ecosystem ensure that they </ins> only store tokens for a small number of them.  In particular, if <del> clients limit their storage of redemption tokens to the bound implied </del> <ins> Clients limit their storage of redemption tokens to the bound implied </ins> by I, then prevents a malicious verifier from triggering redemptions <del> for all servers in the ecosystem. 11. The Privacy Pass protocol and ecosystem are both intended to be receptive to extensions that expand the current set of functionality. As specified in I-D.ietf-privacypass-protocol, all extensions to the Privacy Pass protocol SHOULD be specified as separate documents that modify the content of this document in some way.  We provide guidance on the type of modifications that are possible in the following. Any such extension should also come with a detailed analysis of the privacy impacts of the extension, why these impacts are justified, and guidelines on changes to the parametrization in parametrization. Similarly, extensions MAY also add new server running modes, if applicable, to those that are documented in running-modes. Any extension to the Privacy Pass protocol must adhere to the guidelines specified in key-mgmt for managing server public key data. 12. The following is a non-exhaustive list of applications that currently make use of the Privacy Pass protocol, or some variant of the underlying functionality. 12.1. Cloudflare uses an implementation of the Privacy Pass protocol for allowing clients that have previously interacted with their Internet challenge protection system to bypass future challenges PPSRV.  These challenges can be expensive for clients, and there have been cases where bugs in the implementations can severely degrade client accessibility. Clients must install a browser extension PPEXT that acts as the Privacy Pass client in an exchange with Cloudflare's Privacy Pass server, when an initial challenge solution is provided.  The client extension stores the issued tokens and presents a valid redemption token when it sees future Cloudflare challenges.  If the redemption token is verified by the server, the client passes through the security mechanism without completing a challenge. 12.2. The Trust Token API TrustTokenAPI has been devised as a generic API for providing Privacy Pass functionality in the browser setting.  The API is intended to be implemented directly into browsers so that server's can directly trigger the Privacy Pass workflow. 12.3. The PrivateStorage API developed by Least Authority is a solution for uploading and storing end-to-end encrypted data in the cloud.  A recent addition to the API PrivateStorage allows clients to generate Zero-knowledge Access Passes (ZKAPs) that the client can use to show that it has paid for the storage space that it is using.  The ZKAP protocol is based heavily on the Privacy Pass redemption mechanism. The client receives ZKAPs when it pays for storage space, and redeems the passes when it interacts with the PrivateStorage API. 12.4. The browser Brave uses Basic Attention Tokens (BATs) to provide the basis for an anonymity-preserving rewards scheme Brave.  The BATs are essentially Privacy Pass redemption tokens that are provided by a central Brave server when a client performs some action that triggers a reward event (such as watching an advertisement).  When the client amasses BATs, it can redeem them with the Brave central server for rewards. 12.5. Similarly to BATs, a more generic approach for providing anonymous peers to purchase resources from anonymous servers has been proposed OpenPrivacy.  The protocol is based on a variant of Privacy Pass and is intended to allow clients purchase (or pre-purchase) services such as message hosting, by using Privacy Pass redemption tokens as a form of currency.  This is also similar to how ZKAPs are used. </del> <ins> for all Issuers in the ecosystem. </ins>

Discussion:
This reshuffles quite a bit to frame Privacy Pass as two protocols -- issuance and redemption -- run between Clients, Mediators, Issuers, and Origins. First draft, so there may be things we want to rephrase or reflow. Rendered view of this PR .
Whitespace errors?
NAME fixed!
Merging this per the discussion during the interim meeting today.
A few comments; thanks for the quick turnaround!