minor touchups on proposals

svn:r15263

doc/spec/proposals/000-index.txt

@@ -42,7 +42,7 @@ Proposals by number:
 117  IPv6 exits [NEEDS-REVISION]
 118  Advertising multiple ORPorts at once [DRAFT]
 119  New PROTOCOLINFO command for controllers [CLOSED]
-120  Suicide descriptors when Tor servers stop [OPEN]
+120  Shutdown descriptors when Tor servers stop [OPEN]
 121  Hidden Service Authentication [OPEN]
 122  Network status entries need a new Unnamed flag [CLOSED]
 123  Naming authorities automatically create bindings [CLOSED]
@@ -73,7 +73,7 @@ Proposals by status:
    133  Incorporate Unreachable ORs into the Tor Network
    134  More robust consensus voting with diverse authority sets
  OPEN:
-   120  Suicide descriptors when Tor servers stop
+   120  Shutdown descriptors when Tor servers stop
    121  Hidden Service Authentication
    135  Simplify Configuration of Private Tor Networks
    137  Keep controllers informed as Tor bootstraps

doc/spec/proposals/120-suicide-descriptors.txt → doc/spec/proposals/120-shutdown-descriptors.txt

@@ -1,5 +1,5 @@
-Filename: 120-suicide-descriptors.txt
+Filename: 120-shutdown-descriptors.txt
-Title: Suicide descriptors when Tor servers stop
+Title: Shutdown descriptors when Tor servers stop
 Version: $Revision$
 Last-Modified: $Date$
 Author: Roger Dingledine
@@ -56,11 +56,11 @@ Overhead issues:
 
   We are creating more descriptors that want to be remembered. However,
   since the router won't be marked as Running, ordinary clients won't
-  fetch the suicide descriptors. Caches will, though. I hope this is ok.
+  fetch the shutdown descriptors. Caches will, though. I hope this is ok.
 
 Implementation:
 
-  To make things easy, we should publish the suicide descriptor only
+  To make things easy, we should publish the shutdown descriptor only
   on controlled shutdown (SIGINT as opposed to SIGTERM). That would
   leave enough time for publishing that we probably wouldn't need any
   extra synchronization code.
@@ -76,9 +76,6 @@ Acknowledgements:
 
 Comments:
 
-  1) Don't name the official feature "suicide descriptors".  Suicide is
-     irreversible, and the concept pushes many people's buttons. How about
-     "shutdown descriptors"?
   2) Maybe add a rule "Don't do this for hibernation if we expect to wake
      up before the next consensus is published"?
-                                                      - NM 9 Oct 2007
+                                                      - NM 9 Oct 2007

doc/spec/proposals/138-remove-down-routers-from-consensus.txt

@@ -23,7 +23,7 @@ Status: Closed
 
   At a typical bootstrap a client downloads a 140KB consensus, about
   10KB of certificates to verify that consensus, and about 1.6MB of
-  server descriptors, about half of which it requires before it will
+  server descriptors, about 1/4 of which it requires before it will
   start building circuits.
 
   Another proposal deals with how to get that huge 1.6MB fraction to
@@ -33,8 +33,8 @@ Status: Closed
   to get in order to work.
 
   About one third of the routers listed in a consensus are not running
-  and will therefor never be used by clients who use this consensus.
+  and will therefore never be used by clients who use this consensus.
-  Not listing those routers will safe about 30% to 40% in size.
+  Not listing those routers will save about 30% to 40% in size.
 
 3. Proposed change
 
@@ -47,3 +47,4 @@ Status: Closed
   they support method 4 then this new method will be used:  The
   consensus document is formed like before but a new last step removes
   all routers from the listing that are not marked as Running.
+

doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt

@@ -34,7 +34,7 @@ Goals
    We need to make sure this information isn't exposed in a way that
    helps an adversary.
 
-Methods for curent clients:
+Methods for current clients:
 
    Every client downloads network status documents.  There are
    currently three methods (one hypothetical) for clients to get them.
@@ -49,7 +49,7 @@ Methods for curent clients:
 
         [In both of the above cases, clients choose a running
         directory cache at random with odds roughly proportional to
-        its bandwidth.  If they're just starting, they know a ]
+        its bandwidth.  If they're just starting, they know a XXXX FIXME -NM]
 
       - In some future version, clients will choose directory caches
         to serve as their "directory guards" to avoid profiling
@@ -82,12 +82,12 @@ Methods for curent clients:
 
     Notes:
        - [Over H hours, the N for V2 clients is 2*H, and the N for V3
-         clients is currently around N/2 or N/3.]
+         clients is currently around H/2 or H/3.]
 
        - (We should only count requests that we actually intend to answer;
          503 requests shouldn't count.)
 
-       - These measurements should also be be taken at a directory
+       - These measurements should also be taken at a directory
          authority if possible: their picture of the network is skewed
          by clients that fetch from them directly.  These clients,
          however, are all the clients that are just bootstrapping