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

1 files changed, 8 insertions, 8 deletions

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.
+