spelling fixes for proposals

4 files changed, 11 insertions, 11 deletions

diff --git a/doc/spec/proposals/149-using-netinfo-data.txt b/doc/spec/proposals/149-using-netinfo-data.txt
index cbfc759f22..8bf8375d5d 100644
--- a/doc/spec/proposals/149-using-netinfo-data.txt
+++ b/doc/spec/proposals/149-using-netinfo-data.txt
@@ -22,14 +22,14 @@ Motivation
    idea of their own IP addresses, so they can publish correct
    descriptors.  This is also in NETINFO cells.
 
-Learning the time and IP
+Learning the time and IP address
 
    We need to think about attackers here.  Just because a router tells
    us that we have a given IP or a given clock skew doesn't mean that
    it's true.  We believe this information only if we've heard it from
    a majority of the routers we've connected to recently, including at
    least 3 routers.  Routers only believe this information if the
-   majority inclues at least one authority.
+   majority includes at least one authority.
 
 Avoiding MITM attacks
 
diff --git a/doc/spec/proposals/158-microdescriptors.txt b/doc/spec/proposals/158-microdescriptors.txt
index 59c14c3bcc..c8a35422f8 100644
--- a/doc/spec/proposals/158-microdescriptors.txt
+++ b/doc/spec/proposals/158-microdescriptors.txt
@@ -58,8 +58,8 @@ Status: Open
   A microdescriptor should in every case be a pure function of the
   router descriptor and the conensus method.
 
-  In votes, need to include the hash of each expected microdescriptor in
-  the routerstatus section. I suggest a new "m" line for each stanza,
+  In votes, we need to include the hash of each expected microdescriptor
+  in the routerstatus section. I suggest a new "m" line for each stanza,
   with the base64 of the SHA256 hash of the router's microdescriptor.
 
   For every consensus method that an authority supports, it includes a
@@ -84,7 +84,7 @@ Status: Open
 
 3.1.2. Computing consensus for microdescriptor-elements and "m" lines
 
-  When we generating a consensus, we use whichever m line
+  When we are generating a consensus, we use whichever m line
   unambiguously corresponds to the descriptor digest that will be
   included in the consensus.  (If there are multiple m lines for that
   descriptor digest, we use whichever is most common.  If they are
@@ -103,7 +103,7 @@ Status: Open
 
   This flavor can safely omit descriptor digests.
 
-  We still need to descide whether to move ports into microdescriptors
+  We still need to decide whether to move ports into microdescriptors
   or not.  In either case, they can be removed from the current "ns"
   flavor of consensus, since no current clients use them, and they
   take up about 5% of the compressed consensus.
diff --git a/doc/spec/proposals/162-consensus-flavors.txt b/doc/spec/proposals/162-consensus-flavors.txt
index 80fee1e688..da1405749d 100644
--- a/doc/spec/proposals/162-consensus-flavors.txt
+++ b/doc/spec/proposals/162-consensus-flavors.txt
@@ -37,7 +37,7 @@ Motivation:
 
 Design in brief:
 
-   Let the voting process will remain as it is, until a consensus is
+   Let the voting process remain as it is, until a consensus is
    generated.  With future versions of the voting algorithm, instead
    of just a single consensus being generated, multiple consensus
    "flavors" are produced.
@@ -116,7 +116,7 @@ Spec modifications:
        Signature = "directory-signature" SP algname SP identity
                            SP signing-key-digest NL signature
 
-    There must be one Document line for each generated consensus flavor
+    There must be one Document line for each generated consensus flavor.
     Each Document line describes the length of the signed portion of
     a consensus (the signatures themselves are not included), along
     with one or more digests of that signed portion.  Digests are
diff --git a/doc/spec/proposals/165-simple-robust-voting.txt b/doc/spec/proposals/165-simple-robust-voting.txt
index e33d1772c9..f813285a83 100644
--- a/doc/spec/proposals/165-simple-robust-voting.txt
+++ b/doc/spec/proposals/165-simple-robust-voting.txt
@@ -51,14 +51,14 @@ Proposed protocol design:
 
    A "Voting Set" is a set of authorities.  Each authority has a list of
    the voting sets it considers acceptable.  These sets are chosen
-   manually by the authority operators. they must always contain the
+   manually by the authority operators. They must always contain the
    authority itself.  Each authority lists all of these voting sets in
    its votes.
 
    Authorities exchange votes with every other authority in any of their
    voting sets.
 
-   When it comes time to calculate a consensus, an authority votes with
+   When it is time to calculate a consensus, an authority votes with
    whichever voting set it lists that is listed by the most members of
    that set.  In other words, given two sets S1 and S2 that an authority
    lists, that authority will prefer to vote with S1 over S2 whenever
@@ -116,7 +116,7 @@ Data format changes:
    implement the proposal), add this line to the consensus format as
    well, before the first dir-source line.  [This information is not
    redundant with the dir-source sections in the consensus: If an
-   authority is recognized didn't vote, that authority will appear in
+   authority is recognized but didn't vote, that authority will appear in
    the voting-set line but not in the dir-source sections.]
 
    We don't need to list other information about authorities in our