[or-cvs] r16060: Mark some proposals as written in TODO (in tor/trunk: . doc)

[nickm at seul.org]

Author: nickm
Date: 2008-07-18 14:36:23 -0400 (Fri, 18 Jul 2008)
New Revision: 16060

Modified:
   tor/trunk/
   tor/trunk/doc/TODO
Log:
 r17187 at tombo:  nickm | 2008-07-18 14:20:51 -0400
 Mark some proposals as written in TODO



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r17187] on 49666b30-7950-49c5-bedf-9dc8f3168102

Modified: tor/trunk/doc/TODO
===================================================================
--- tor/trunk/doc/TODO	2008-07-18 18:10:29 UTC (rev 16059)
+++ tor/trunk/doc/TODO	2008-07-18 18:36:23 UTC (rev 16060)
@@ -238,29 +238,30 @@
         (This is very similar to proposal 118.)
     - Fix voting to handle bug 608 case when multiple servers get
       Named.
-    - Possibly: revise link protocol to allow big circuit IDs,
+    d Possibly: revise link protocol to allow big circuit IDs,
       variable-length cells, proposal-110 stuff, and versioned CREATES?
-    - Eliminate use of v2 networkstatus documents in v3 authority
+    o Eliminate use of v2 networkstatus documents in v3 authority
       decision-making.
 N   . Draft proposal for GeoIP aggregation (see external constraints *)
-    - Separate Guard flags for "pick this as a new guard" and "keep this
+    o Separate Guard flags for "pick this as a new guard" and "keep this
       as an existing guard".  First investigate if we want this.
-    - Figure out how to make good use of the fallback consensus file. Right
+    . Figure out how to make good use of the fallback consensus file. Right
       now many of the addresses in the fallback consensus will be stale,
       so it will take dozens of minutes to bootstrap from it. This is a
       bad first Tor experience. But if we check the fallback consensus
       file *after* we fail to connect to any authorities, then it may
       still be valuable as a blocking-resistance step.
+      o Write the proposal.
       - Patch our tor.spec rpm package so it knows where to put the fallback
         consensus file.
-    - Something for bug 469, to limit connections per IP.
-    - Put bandwidth weights in the networkstatus? So clients get weight
+    d Something for bug 469, to limit connections per IP.
+    . Put bandwidth weights in the networkstatus? So clients get weight
       their choices even before they have the descriptors; and so
       authorities can put in more accurate numbers in the future.
     d Fetch an updated geoip file from the directory authorities.
 
   - Tiny designs to write:
-    - Better estimate of clock skew; has anonymity implications.  Clients
+    . Better estimate of clock skew; has anonymity implications.  Clients
       should estimate their skew as median of skew from servers over last
       N seconds, but for servers this is not so easy, since a server does
       not choose who it connects to.