proposals tweaks patch

is attached

--roger

>From 674f087ab98e1711bb533acf23ee88c7c2a1dfdb Mon Sep 17 00:00:00 2001
From: Roger Dingledine <arma@torproject.org>
Date: Sun, 7 Jun 2009 14:37:32 -0400
Subject: [PATCH] minor edits on proposals

2 files changed, 12 insertions, 11 deletions

diff --git a/proposals/158-microdescriptors.txt b/proposals/158-microdescriptors.txt
index c8a3542..6f53b9d 100644
--- a/proposals/158-microdescriptors.txt
+++ b/proposals/158-microdescriptors.txt
@@ -8,7 +8,7 @@ Status: Open
 
   15 May 2009: Substantially revised based on discussions on or-dev
   from late January.  Removed the notion of voting on how to choose
-  microdescriptors; made it just a function of the consesus method.
+  microdescriptors; made it just a function of the consensus method.
   (This lets us avoid the possibility of "desynchronization.")
   Added suggestion to use a new consensus flavor.  Specified use of
   SHA256 for new hashes. -nickm
@@ -47,7 +47,7 @@ Status: Open
 3. Design
 
   There are three pieces to the proposal. First, authorities will list in
-  their votes (and thus in the consensus)  the expected hash
+  their votes (and thus in the consensus) the expected hash
   of microdescriptor for each relay. Second, directory mirrors will serve
   microdescriptors. Third, clients will ask for them and cache them.
 
@@ -111,7 +111,7 @@ Status: Open
   This new consensus flavor should be signed with the sha256 signature
   format as documented in proposal 162.
 
-3.2. Directory mirrors serve microdescriptors
+3.2. Directory mirrors fetch, cache, and serve microdescriptors
 
   Directory mirrors should then read the microdescriptor-elements line
   from the consensus, and learn how to answer requests. (Directory mirrors
@@ -122,6 +122,7 @@ Status: Open
     http://<hostname>/tor/micro/d/<D1>-<D2>-<D3>.z
   (We use base64 for size and for consistency with the consensus
   format. We use -s instead of +s to separate these items, since
+  ... since...?
 
   All the microdescriptors from the current consensus should also be
   available at:
diff --git a/proposals/162-consensus-flavors.txt b/proposals/162-consensus-flavors.txt
index da14057..caff96c 100644
--- a/proposals/162-consensus-flavors.txt
+++ b/proposals/162-consensus-flavors.txt
@@ -5,7 +5,6 @@ Created: 14-May-2009
 Target: 0.2.2
 Status: Open
 
-
 Overview:
 
    This proposal describes a way to publish each consensus in
@@ -67,8 +66,8 @@ Spec modifications:
    The supported consensus flavors are defined as part of the
    authorities' consensus method.
 
-   For each supported flavors, every authority calculates another
-   consensus document of as-yet-unspecified format, and exchange
+   For each supported flavor, every authority calculates another
+   consensus document of as-yet-unspecified format, and exchanges
    detached signatures for these documents as in the current consensus
    design.
 
@@ -112,7 +111,7 @@ Spec modifications:
        Documents = Document*
        Document = "document" SP flavor SP SignedLength
                                     1*(SP AlgorithmName "=" Digest) NL
-       Signatures = Signature *
+       Signatures = Signature*
        Signature = "directory-signature" SP algname SP identity
                            SP signing-key-digest NL signature
 
@@ -141,15 +140,15 @@ Spec modifications:
 
     The 'SHA256' signature format for directory objects is defined as
     the RSA signature of the OAEP+-padded SHA256 digest of the SHA256
-    digest of the the item to be signed.  When checking signatures,
-    the signature MUST be treated as valid if the signed material
+    digest of the item to be signed.  When checking signatures,
+    the signature MUST be treated as valid if the signature material
     begins with SHA256(SHA256(document)); this allows us to add other
     data later.
 
 Considerations:
 
     - We should not create a new flavor of consensus when adding a
-      field wouldn't be too onerous.
+      field instead wouldn't be too onerous.
 
     - We should not proliferate flavors lightly: clients will be
       distinguishable based on which flavor they download.
@@ -159,7 +158,7 @@ Migration:
     - Stage one: authorities begin generating and serving
       consensus-index files.
 
-    - Stage two: Caches begin downloading consenusus-index files,
+    - Stage two: Caches begin downloading consensus-index files,
       validating them, and using them to decide what flavors of
       consensus documents to cache.  They download all listed
       documents, and compare them to the digests given in the
@@ -176,3 +175,4 @@ Acknowledgements:
 
     Aspects of this design and its applications to hash migration were
     heavily influenced by IRC conversations with Marian.
+