[tor-commits] [torspec/master] some typo fixes i found in my sandbox

[arma at torproject.org]

commit d48eaa7db2b165b2e1f5817381d978f498806525
Author: Roger Dingledine <arma at torproject.org>
Date:   Sun Apr 14 16:30:51 2013 -0400

    some typo fixes i found in my sandbox
---
 proposals/205-local-dnscache.txt |    7 ++++---
 proposals/216-ntor-handshake.txt |    4 +---
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/proposals/205-local-dnscache.txt b/proposals/205-local-dnscache.txt
index 624e793..d0a0107 100644
--- a/proposals/205-local-dnscache.txt
+++ b/proposals/205-local-dnscache.txt
@@ -28,8 +28,9 @@ Status: Closed
    cache.  This lets us implement exit policies and exit enclaves --
    if we remember that www.mit.edu is 18.9.22.169 the first time we
    see it, then we can avoid making future requests for www.mit.edu
-   via any node that blocks net 18.  Also, if there happened to be a
-   Tor node at 18.9.22.169, we could use that node as an exit enclave.
+   via any node whose exit policy refuses net 18.  Also, if there
+   happened to be a Tor node at 18.9.22.169, we could use that node as
+   an exit enclave.
 
    But there are security issues with DNS caches.  A malicious exit
    node or DNS server can lie.  And unlike other traffic, where the
@@ -94,7 +95,7 @@ Status: Closed
    controller, the configuration file, trackhostexits maps,
    virtual-address maps, DNS replies, and so on.
 
-   With this design, the DNS cache will not be part of the address
+   With this proposed design, the DNS cache will not be part of the address
    map.  That means that entries in the address map which relied on
    happening after the DNS cache entries can no longer work so well.
    These would include:
diff --git a/proposals/216-ntor-handshake.txt b/proposals/216-ntor-handshake.txt
index e0c4f63..f76e81c 100644
--- a/proposals/216-ntor-handshake.txt
+++ b/proposals/216-ntor-handshake.txt
@@ -85,7 +85,7 @@ Protocol:
   The server sends a CREATED cell containing:
 
     SERVER_PK:  Y                     -- G_LENGTH bytes
-    AUTH:       H(auth_input, t_mac)  -- H_LENGTH byets
+    AUTH:       H(auth_input, t_mac)  -- H_LENGTH bytes
 
   The client then checks Y is in G^* [see NOTE below], and computes
 
@@ -211,5 +211,3 @@ Test vectors for HKDF-SHA256:
           b4dc21d69363e2895321c06184879d94b18f0784
           11be70b767c7fc40679a9440a0c95ea83a23efbf
 
-
-