Script updating gh-pages from 94db926. [ci skip]

draft-ietf-privacypass-architecture.html

@@ -1400,7 +1400,7 @@ <h2 id="name-architecture">
 privacy goals of the architecture, and the goals and requirements of
 the redemption and issuance protocols. Deployment variations for the
 Origin, Issuer, and Attester in this architecture, including
-considerations for implements these entities, are further discussed
+considerations for implementing these entities, are further discussed
 in <a href="#deployment" class="auto internal xref">Section 4</a>.<a href="#section-3-1" class="pilcrow">¶</a></p>
 <div id="overview">
 <section id="section-3.1">
@@ -2556,7 +2556,7 @@ <h2 id="name-privacy-considerations">
 unlinkable. For example, consider two different deployments, one wherein
 there exists a redemption anonymity set of size two and another
 wherein there redemption anonymity set of size 2<sup>32</sup>. Although
-Origin-Client unlinkabiity guarantees that the Origin cannot link any two
+Origin-Client unlinkability guarantees that the Origin cannot link any two
 requests to the same Client based on these contexts, respectively, the
 probability of determining the "true" Client is higher the smaller these
 sets become.<a href="#section-6-1" class="pilcrow">¶</a></p>
@@ -2612,7 +2612,7 @@ <h3 id="name-partitioning-by-issuance-co">
 <p id="section-6.2-3">The number of active Issuer configurations also contributes to anonymity set
 partitioning. In particular, when an Issuer updates their configuration and
 the corresponding key pair, any Client that invokes the issuance protocol with
-this configuration becomes be part of a set of Clients which also ran the
+this configuration becomes part of a set of Clients which also ran the
 issuance protocol using the same configuration. Issuer configuration updates,
 e.g., due to key rotation, are an important part of hedging against long-term
 private key compromise. In general, key rotations represent a trade-off between
@@ -2691,7 +2691,7 @@ <h3 id="name-token-caching">
 <p id="section-7.1-3">Moreover, since tokens are not intrinsically bound to Clients, it is possible
 for malicious Clients to collude and share tokens in a so-called "hoarding
 attack." As an example of this attack, many distributed Clients could obtain
-cacheable tokens and them share them with a single Client to redeem in a way
+cacheable tokens and then share them with a single Client to redeem in a way
 that would violate an Origin's attempt to limit tokens to any one particular
 Client. In general, mechanisms for mitigating hoarding attacks depend on the
 deployment model and use case. For example, in the Joint Origin and Issuer model,

draft-ietf-privacypass-architecture.txt

@@ -185,7 +185,7 @@ Table of Contents
    privacy goals of the architecture, and the goals and requirements of
    the redemption and issuance protocols.  Deployment variations for the
    Origin, Issuer, and Attester in this architecture, including
-   considerations for implements these entities, are further discussed
+   considerations for implementing these entities, are further discussed
    in Section 4.
 
 3.1.  Overview
@@ -1089,7 +1089,7 @@ Table of Contents
    example, consider two different deployments, one wherein there exists
    a redemption anonymity set of size two and another wherein there
    redemption anonymity set of size 2^32.  Although Origin-Client
-   unlinkabiity guarantees that the Origin cannot link any two requests
+   unlinkability guarantees that the Origin cannot link any two requests
    to the same Client based on these contexts, respectively, the
    probability of determining the "true" Client is higher the smaller
    these sets become.
@@ -1150,9 +1150,9 @@ Table of Contents
    The number of active Issuer configurations also contributes to
    anonymity set partitioning.  In particular, when an Issuer updates
    their configuration and the corresponding key pair, any Client that
-   invokes the issuance protocol with this configuration becomes be part
-   of a set of Clients which also ran the issuance protocol using the
-   same configuration.  Issuer configuration updates, e.g., due to key
+   invokes the issuance protocol with this configuration becomes part of
+   a set of Clients which also ran the issuance protocol using the same
+   configuration.  Issuer configuration updates, e.g., due to key
    rotation, are an important part of hedging against long-term private
    key compromise.  In general, key rotations represent a trade-off
    between Client privacy and Issuer security.  Therefore, it is
@@ -1226,7 +1226,7 @@ Table of Contents
    Moreover, since tokens are not intrinsically bound to Clients, it is
    possible for malicious Clients to collude and share tokens in a so-
    called "hoarding attack."  As an example of this attack, many
-   distributed Clients could obtain cacheable tokens and them share them
+   distributed Clients could obtain cacheable tokens and then share them
    with a single Client to redeem in a way that would violate an
    Origin's attempt to limit tokens to any one particular Client.  In
    general, mechanisms for mitigating hoarding attacks depend on the