cleanup proposals as i read them

5 files changed, 50 insertions, 43 deletions

diff --git a/proposals/168-reduce-circwindow.txt b/proposals/168-reduce-circwindow.txt
index c10cf41..a746286 100644
--- a/proposals/168-reduce-circwindow.txt
+++ b/proposals/168-reduce-circwindow.txt
@@ -37,7 +37,7 @@ Target: 0.2.2
   The median round-trip latency appears to be around 2s, with 25% of
   the data points taking more than 5s. That's a lot of variance.
 
-  We designed Tor originally with the original goal of maximizing
+  We designed Tor originally with the goal of maximizing
   throughput. We figured that would also optimize other network properties
   like round-trip latency. Looks like we were wrong.
 
diff --git a/proposals/169-eliminating-renegotiation.txt b/proposals/169-eliminating-renegotiation.txt
index 2c90f9c..6311124 100644
--- a/proposals/169-eliminating-renegotiation.txt
+++ b/proposals/169-eliminating-renegotiation.txt
@@ -31,7 +31,7 @@ Target: 0.2.2
    In the current Tor TLS connection handshake protocol ("V2", or
    "renegotiating"), the parties begin with a single certificate
    sent from the server (responder) to the client (initiator), and
-   then renegotiate to a two-certs-from-each-authenticating party.
+   then renegotiate to a two-certs-from-each-authenticating-party.
    We made this change to make Tor's handshake look like a browser
    speaking SSL to a webserver.  (See proposal 130, and
    tor-spec.txt.)  To tell whether to use the V1 or V2 handshake,
@@ -171,7 +171,7 @@ Target: 0.2.2
    On learning the link protocol, the server then sends the client a
    CERT cell and a NETINFO cell.  If the client wants to
    authenticate to the server, it sends a CERT cell, an AUTHENTICATE
-   cell, and a NETINFO cell, or it may simply send a NETINFO cell if
+   cell, and a NETINFO cell; or it may simply send a NETINFO cell if
    it does not want to authenticate.
 
    The CERT cell describes the keys that a Tor instance is claiming
@@ -199,7 +199,7 @@ Target: 0.2.2
    where CertType is 1 (meaning "RSA/SHA256")
          CertPurpose is 1 (meaning "link certificate")
          PublicKey is the DER encoding of the ASN.1 representation
-            of the RSA key of the subject of this certificate,
+            of the RSA key of the subject of this certificate
          NotBefore is a time in HOURS since January 1, 1970, 00:00
             UTC before which this certificate should not be
             considered valid.
@@ -208,7 +208,7 @@ Target: 0.2.2
             considered valid.
          SignerID is the SHA-256 digest of the public key signing
             this certificate
-         and Signature is the signature of the all other fields in
+         and Signature is the signature of all the other fields in
             this certificate, using SHA256 as described in proposal
             158.
 
@@ -362,12 +362,12 @@ Target: 0.2.2
    We need to reserve command numbers for CERT and AUTH cells.  I
    suggest that in link protocol 3 and higher, we reserve command
    numbers 128..240 for variable-length cells.  (241-256 we can hold
-   for future extensions.
+   for future extensions.)
 
 5. Efficiency
 
-   This protocol add a round-trip step when the client sends a
-   VERSIONS cell to the server, and waits for the {VERSIONS, CERT,
+   This protocol adds a round-trip step when the client sends a
+   VERSIONS cell to the server and waits for the {VERSIONS, CERT,
    NETINFO} response in turn.  (The server then waits for the
    client's {NETINFO} or {CERT, AUTHENTICATE, NETINFO} reply,
    but it would have already been waiting for the client's NETINFO,
@@ -402,3 +402,4 @@ Target: 0.2.2
   - What should servers that don't have TLS renegotiation do?  For
     now, I think they should just get it.  Eventually we can
     deprecate the V2 handshake as we did with the V1 handshake.
+
diff --git a/proposals/173-getinfo-option-expansion.txt b/proposals/173-getinfo-option-expansion.txt
index 03e18ef..54356c9 100644
--- a/proposals/173-getinfo-option-expansion.txt
+++ b/proposals/173-getinfo-option-expansion.txt
@@ -7,7 +7,7 @@ Status: Accepted
 Overview:
 
     Over the course of developing arm there's been numerous hacks and
-    workarounds to gleam pieces of basic, desirable information about the tor
+    workarounds to glean pieces of basic, desirable information about the tor
     process. As per Roger's request I've compiled a list of these pain points
     to try and improve the control protocol interface.
 
@@ -15,19 +15,19 @@ Motivation:
 
     The purpose of this proposal is to expose additional process and relay
     related information that is currently unavailable in a convenient,
-    dependable, and/or platform independent way. Examples of this are...
-    
+    dependable, and/or platform independent way. Examples are:
+
       - The relay's total contributed bandwidth. This is a highly requested
         piece of information and, based on the following patch from pipe, looks
         trivial to include.
         http://www.mail-archive.com/or-talk@freehaven.net/msg13085.html
-      
+
       - The process ID of the tor process. There is a high degree of guess work
         in obtaining this. Arm for instance uses pidof, netstat, and ps yet
         still fails on some platforms, and Orbot recently got a ticket about
         its own attempt to fetch it with ps:
         https://trac.torproject.org/projects/tor/ticket/1388
-    
+
     This just includes the pieces of missing information I've noticed
     (suggestions or questions of their usefulness are welcome!).
 
@@ -39,43 +39,45 @@ Security Implications:
 Specification:
 
     The following addition would be made to the control-spec's GETINFO section:
-    
+
     "relay/bw-limit" -- Effective relayed bandwidth limit.
-    
+
     "relay/burst-limit" -- Effective relayed burst limit.
-    
+
     "relay/read-total" -- Total bytes relayed (download).
-    
+
     "relay/write-total" -- Total bytes relayed (upload).
-    
+
     "relay/flags" -- Space separated listing of flags currently held by the
-    relay as repored by the currently cached consensus.
-    
+    relay as reported by the currently cached consensus.
+
     "process/user" -- Username under which the tor process is running,
-    providing an empty string if none exists.
-    
+    or an empty string if none exists.
+    [what do we mean 'if none exists'?]
+
     "process/pid" -- Process id belonging to the main tor process, -1 if none
     exists for the platform.
-    
+
     "process/uptime" -- Total uptime of the tor process (in seconds).
-    
+
     "process/uptime-reset" -- Time since last reset (startup, sighup, or RELOAD
-    signal, in seconds).
-    
+    signal, in seconds). [should clarify exactly which events cause an
+    uptime reset]
+
     "process/descriptors-used" -- Count of file descriptors used.
-    
+
     "process/descriptor-limit" -- File descriptor limit (getrlimit results).
-    
+
     "ns/authority" -- Router status info (v2 directory style) for all
     recognized directory authorities, joined by newlines.
-    
+
     "state/names" -- A space-separated list of all the keys supported by this
     version of Tor's state.
-    
+
     "state/val/<key>" -- Provides the current state value belonging to the
     given key. If undefined, this provides the key's default value.
-    
-    "status/ports-seen" -- A summary of which ports we've seen connections
+
+    "status/ports-seen" -- A summary of which ports we've seen connections'
     circuits connect to recently, formatted the same as the EXITS_SEEN status
     event described in Section 4.1.XX. This GETINFO option is currently
     available only for exit relays.
@@ -90,7 +92,7 @@ Specification:
   in their "relay" configuration window, to give them a sense of how they're
   being used (popularity of the various ports they exit to). Currently only
   exit relays will receive this event.
-  
+
   TimeStarted is a quoted string indicating when the reported summary
   counts from (in GMT).
 
diff --git a/proposals/175-automatic-node-promotion.txt b/proposals/175-automatic-node-promotion.txt
index c990b3f..f97cec0 100644
--- a/proposals/175-automatic-node-promotion.txt
+++ b/proposals/175-automatic-node-promotion.txt
@@ -175,6 +175,8 @@ Status: Draft
    might as well be a new one with no history. This policy may change
    once we start allowing the bridge authority to hand out new IP
    addresses given the fingerprint.
+   [Perhaps another consensus param? Also, this means we save previous
+    IP address in our state file, yes? -RD]
 
 3.x Bandwidth measurement
 
@@ -222,7 +224,7 @@ Status: Draft
      * Publication of IP address
      * Blocking from IRC (even for non-exit relays)
 
-   - What feedback should we give to bridge relays, to encourage then
+   - What feedback should we give to bridge relays, to encourage them
      e.g. number of recent users (what about reserve bridges)?
 
    - Can clients back-off from doing these tests (yes, we should do
diff --git a/proposals/ideas/xxx-pluggable-transport.txt b/proposals/ideas/xxx-pluggable-transport.txt
index 53ba9c6..c23ba92 100644
--- a/proposals/ideas/xxx-pluggable-transport.txt
+++ b/proposals/ideas/xxx-pluggable-transport.txt
@@ -109,13 +109,13 @@ Design overview
 
   To write a new transport protocol, an implementer must provide two
   pieces: a "Client Proxy" to run at the initiator side, and a "Server
-  Proxy" to run a the server side.  These two pieces may or may not be
+  Proxy" to run at the server side.  These two pieces may or may not be
   implemented by the same program.
 
   Each client may run any number of Client Proxies.  Each one acts like
-  a SOCKS proxy that accepts accept connections on localhost.  Each one
+  a SOCKS proxy that accepts connections on localhost.  Each one
   runs on a different port, and implements one or more transport
-  methods.  If the protocol has any parameters, they passed from Tor
+  methods.  If the protocol has any parameters, they are passed from Tor
   inside the regular username/password parts of the SOCKS protocol.
 
   Bridges (and maybe relays) may run any number of Server Proxies: these
@@ -147,7 +147,7 @@ Specifications: Client behavior
   on the TLS connection to match the digest provided in
   [id-fingerprint].  If any [k=v] items are provided, they are
   configuration parameters for the proxy: Tor should separate them with
-  semicolons and put them user and password fields of the request,
+  semicolons and put them in the user and password fields of the request,
   splitting them across the fields as necessary.  If a key or value
   value must contain a semicolon or a backslash, it is escaped with a
   backslash.
@@ -174,6 +174,7 @@ Specifications: Client behavior
   connections. The Tor client only launches one instance of each
   external program, even if the same executable is listed for more than
   one method.
+  [What if the options are different? -RD]
 
   The same program can implement a managed or an external proxy: it just
   needs to take an argument saying which one to be.
@@ -237,8 +238,8 @@ Server proxy behavior
 
    [If we're using the bridge authority/bridgedb system for distributing
    bridge info, the right place to advertise bridge lines is probably
-   the extrainfo document.  We also need a way to tell the bridge
-   authority "don't give out a default bridge line for me"]
+   the extrainfo document.  We also need a way to tell bridgedb
+   "don't give out a default bridge line for me"]
 
 Server behavior
 
@@ -289,12 +290,12 @@ Appendix: recommendations for transports
   make it either get a small userbase, or poor auditing.
 
   Think secure: if your code is in a C-like language, and it's hard to
-  read it and become convinced it's safe then, it's probably not safe.
+  read it and become convinced it's safe, then it's probably not safe.
 
   Think small: we want to minimize the bytes that a Windows user needs
   to download for a transport client.
 
-  Specify: if you can't come up with a good explanation
+  Specify: if you can't come up with a good explanation [XXX]
 
   Avoid security-through-obscurity if possible.  Specify.
 
@@ -309,4 +310,5 @@ Appendix: recommendations for transports
 Appendix: Raw-traffic transports
 
   This section describes an optional extension to the proposal above.
-  We  are not sure whether it is a good idea.
+  We are not sure whether it is a good idea.
+