update and integrate proposals 125 (bridges) and 137 (bootstrap status)

svn:r16374

4 files changed, 28 insertions, 75 deletions

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 87ff2b9..2747b0f 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -47,7 +47,7 @@ Proposals by number:
 122  Network status entries need a new Unnamed flag [CLOSED]
 123  Naming authorities automatically create bindings [CLOSED]
 124  Blocking resistant TLS certificate usage [SUPERSEDED]
-125  Behavior for bridge users, bridge relays, and bridge authorities [FINISHED]
+125  Behavior for bridge users, bridge relays, and bridge authorities [CLOSED]
 126  Getting GeoIP data and publishing usage summaries [CLOSED]
 127  Relaying dirport requests to Tor download site / website [DRAFT]
 128  Families of private bridges [FINISHED]
@@ -59,7 +59,7 @@ Proposals by number:
 134  More robust consensus voting with diverse authority sets [ACCEPTED]
 135  Simplify Configuration of Private Tor Networks [ACCEPTED]
 136  Mass authority migration with legacy keys [FINISHED]
-137  Keep controllers informed as Tor bootstraps [FINISHED]
+137  Keep controllers informed as Tor bootstraps [CLOSED]
 138  Remove routers that are not Running from consensus documents [CLOSED]
 139  Download consensus documents only when it will be trusted [CLOSED]
 140  Provide diffs between consensuses [ACCEPTED]
@@ -117,10 +117,8 @@ Proposals by status:
    099  Miscellaneous proposals
  FINISHED:
    111  Prioritizing local traffic over relayed traffic
-   125  Behavior for bridge users, bridge relays, and bridge authorities
    128  Families of private bridges
    136  Mass authority migration with legacy keys
-   137  Keep controllers informed as Tor bootstraps
  CLOSED:
    101  Voting on the Tor Directory System
    102  Dropping "opt" from the directory format
@@ -135,9 +133,11 @@ Proposals by status:
    119  New PROTOCOLINFO command for controllers
    122  Network status entries need a new Unnamed flag
    123  Naming authorities automatically create bindings
+   125  Behavior for bridge users, bridge relays, and bridge authorities
    126  Getting GeoIP data and publishing usage summaries
    129  Block Insecure Protocols by Default
    130  Version 2 Tor connection protocol
+   137  Keep controllers informed as Tor bootstraps
    138  Remove routers that are not Running from consensus documents
    139  Download consensus documents only when it will be trusted
    150  Exclude Exit Nodes from a circuit
diff --git a/proposals/125-bridges.txt b/proposals/125-bridges.txt
index bc6de66..8bb3169 100644
--- a/proposals/125-bridges.txt
+++ b/proposals/125-bridges.txt
@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Roger Dingledine
 Created: 11-Nov-2007
-Status: Finished
+Status: Closed
 Implemented-In: 0.2.0.x
 
 0. Preface
@@ -36,52 +36,32 @@ Implemented-In: 0.2.0.x
   which will cause your relay to not publish anywhere. This could be
   useful for private bridges.
 
-1.2. Defining DirPort
-
-  Bridges need to answer BEGIN_DIR requests, both so they can answer
-  "/server/authority" questions ("what's your descriptor?") and so they
-  can supply their bridge users with cached copies of all the various
-  Tor network information.
-
-  As of Tor 0.2.0.13-alpha, bridges will answer begin_dir questions
-  (and cache dir info they see so the answers will be more useful)
-  whether their DirPort is enabled or not. (After all, we don't care if
-  they have an open or reachable DirPort to answer begin_dir questions.)
-
-  We need to investigate if there are any anonymity worries with answering
-  BEGIN_DIR requests when our DirPort is off. I claim that we don't open
-  any new attacks: it's still a fine question to ask what partitioning
-  attacks there are when you can query a Tor client about its current
-  directory opinions, but these attacks already exist when DirPort is on.
-  We should investigate this in 0.2.1.x.
-
-1.3. Exit policy
+1.2. Exit policy
 
   Bridge relays should use an exit policy of "reject *:*". This is
   because they only need to relay traffic between the bridge users
   and the rest of the Tor network, so there's no need to let people
   exit directly from them.
 
-1.4. RelayBandwidthRate / RelayBandwidthBurst
+1.3. RelayBandwidthRate / RelayBandwidthBurst
 
   We invented the RelayBandwidth* options for this situation: Tor clients
   who want to allow relaying too. See proposal 111 for details. Relay
   operators should feel free to rate-limit their relayed traffic.
 
-1.5. Helping the user with port forwarding, NAT, etc.
+1.4. Helping the user with port forwarding, NAT, etc.
 
   Just as for operating normal relays, our documentation and hints for
   how to make your ORPort reachable are inadequate for normal users.
 
-  We need to work harder on this step, perhaps in 0.2.1.x.
+  We need to work harder on this step, perhaps in 0.2.2.x.
 
-1.6. Vidalia integration
+1.5. Vidalia integration
 
-  Vidalia 0.0.15 has turned its "Relay" settings page into a tri-state
+  Vidalia has turned its "Relay" settings page into a tri-state
   "Don't relay" / "Relay for the Tor network" / "Help censored users".
 
-  If you click the third choice, it forces your exit policy to reject *:*,
-  and it forces your DirPort to 9030 (but see Sec 1.2 above about DirPort).
+  If you click the third choice, it forces your exit policy to reject *:*.
 
   If all the bridges end up on port 9001, that's not so good. On the
   other hand, putting the bridges on a low-numbered port in the Unix
@@ -93,7 +73,7 @@ Implemented-In: 0.2.0.x
   the bridge identifier to the operator (see Section 3.1) so he can pass
   it on to bridge users.
 
-1.7. What if the default ORPort is already used?
+1.6. What if the default ORPort is already used?
 
   If the user already has a webserver or some other application
   bound to port 443, then Tor will fail to bind it and complain to the
@@ -102,7 +82,7 @@ Implemented-In: 0.2.0.x
   "ORPort auto" option that tells Tor to try to find something that's
   bindable and reachable. This would also help us tolerate ISPs that
   filter incoming connections on port 80 and port 443. But this should
-  be a different proposal, and can wait until 0.2.1.x.
+  be a different proposal, and can wait until 0.2.2.x.
 
 2. Bridge authorities.
 
@@ -127,25 +107,16 @@ Implemented-In: 0.2.0.x
   annotations, it's easy to look through it and find the bridge-purpose
   descriptors.
 
-  We should work with Tonga to export its router-descriptors file to
-  some place where we can distribute the bridge addresses according to
-  the policies in blocking.pdf. It might even be easier to have it write
-  out a separate file, just for export, that includes only the bridge
-  descriptors; or maybe a six-liner perl postprocessing script is the
-  better plan there to create a file for export.
+  Currently we export the bridge descriptors from Tonga to the
+  BridgeDB server, so it can give them out according to the policies
+  in blocking.pdf.
 
 2.2. Reachability/uptime testing
 
-  Right now the bridge authorities just passively collect bridge
-  descriptors, and give them out on request. At some point we are going
-  to want to recommend new bridges to users, and we'll want to have
-  some way of deciding which ones are up right now, which ones have
-  been around for a while, etc. We should have the bridge authorities
-  do active measurements of bridges just as the normal authorities do
-  active measurements of normal relays. Then we can export the results
-  just like in Section 2.1. above.
+  Right now the bridge authorities do active reachability testing of
+  bridges, so we know which ones to recommend for users.
 
-  In the design document, we suggested that bridges should publish
+  But in the design document, we suggested that bridges should publish
   anonymously (i.e. via Tor) to the bridge authority, so somebody watching
   the bridge authority can't just enumerate all the bridges. But if we're
   doing active measurement, the game is up. Perhaps we should back off on
@@ -164,7 +135,7 @@ Implemented-In: 0.2.0.x
   a random bridge authority. This resolves the robustness bottleneck,
   but makes the trust bottleneck even worse.
 
-  In 0.2.1.x and later we should think about better ways to have multiple
+  In 0.2.2.x and later we should think about better ways to have multiple
   bridge authorities.
 
 3. Bridge users.
@@ -174,10 +145,9 @@ Implemented-In: 0.2.0.x
   entry guards (their first hop) and directory guards (the source of
   all their directory information).
 
-  To become a bridge user, add the following two lines to your torrc:
+  To become a bridge user, add the following line to your torrc:
 
     UseBridges 1
-    TunnelDirConns 1
 
   and then add at least one "Bridge" line to your torrc based on the
   format below.
@@ -293,35 +263,18 @@ Implemented-In: 0.2.0.x
   first attempt, after 15 minutes for the second attempt, and after 60
   minutes for subsequent attempts.
 
-  In 0.2.1.x we should come up with some smarter retry schedules.
+  In 0.2.2.x we should come up with some smarter retry schedules.
 
 3.6. Vidalia integration
 
-  Vidalia 0.0.15 has a new checkbox in its Network config window called
+  Vidalia 0.0.16 has a checkbox in its Network config window called
   "My ISP blocks connections to the Tor network." Users who click that
   box change their configuration to:
-    TunnelDirConns 1
-    PreferTunneledDirConns 1
-
-  Once the box is checked, there is also a section for adding bridge
-  identifiers. When at least one bridge identifier is present, Vidalia
-  also changes their config to:
     UseBridges 1
     UpdateBridgesFromAuthority 1
-  and updates their Bridge config option accordingly.
-
-3.7. When should we make TunnelDirConns default
-
-  Right now Tor's directory requests can be filtered on the network,
-  and some tools used by Middle Eastern governments even do this. A user
-  who wants to circumvent these filters should click the above box in
-  Vidalia 0.0.15. But at what point should we make tunneled directory
-  requests the default?
-
-  Once proposal 124 (modified TLS handshake) is in place, we should
-  consider doing the switch. This might even be in the 0.2.0.x timeframe.
+  and should specify at least one Bridge identifier.
 
-3.8. Do we need a second layer of entry guards?
+3.7. Do we need a second layer of entry guards?
 
   If the bridge user uses the bridge as its entry guard, then the
   triangulation attacks from Lasse and Paul's Oakland paper work to
diff --git a/proposals/137-bootstrap-phases.txt b/proposals/137-bootstrap-phases.txt
index 34800e4..18d3dfa 100644
--- a/proposals/137-bootstrap-phases.txt
+++ b/proposals/137-bootstrap-phases.txt
@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Roger Dingledine
 Created: 07-Jun-2008
-Status: Finished
+Status: Closed
 Implemented-In: 0.2.1.x
 
 1. Overview.
diff --git a/proposals/ideas/xxx-bridge-disbursement.txt b/proposals/ideas/xxx-bridge-disbursement.txt
index 653630c..6c9a3c7 100644
--- a/proposals/ideas/xxx-bridge-disbursement.txt
+++ b/proposals/ideas/xxx-bridge-disbursement.txt
@@ -55,7 +55,7 @@ IP-based.
       approach would also resolve the "Make sure you can't construct a
       distinct address to match an existing one" note below. -RD]
 
-        [I think, if we get a replay, we need to sen back the same
+        [I think, if we get a replay, we need to send back the same
         answer as we did the first time, not say "try again."
         Otherwise we need to worry that an attacker can keep people
         from getting bridges by preemtively asking for them,