[or-cvs] r10606: update the todo, primarily with bridge-related stuff but als (tor/trunk/doc)
arma at seul.org
arma at seul.org
Fri Jun 15 04:14:02 UTC 2007
Author: arma
Date: 2007-06-15 00:14:01 -0400 (Fri, 15 Jun 2007)
New Revision: 10606
Modified:
tor/trunk/doc/TODO
Log:
update the todo, primarily with bridge-related stuff but
also list some dirserv behaviors we should document
Modified: tor/trunk/doc/TODO
===================================================================
--- tor/trunk/doc/TODO 2007-06-15 03:14:02 UTC (rev 10605)
+++ tor/trunk/doc/TODO 2007-06-15 04:14:01 UTC (rev 10606)
@@ -40,8 +40,8 @@
o In man page
- In a good HOWTO.
- - Update dir-spec with decisions made on these issues:
-
+Things we'd like to do in 0.2.0.x:
+ - Update dir-spec with decisions made on these issues:
o clients don't log as loudly when they receive them
o they don't count toward the 3-strikes rule
D But eventually, we give up after getting a lot of 503s.
@@ -53,9 +53,11 @@
D They can 503 client descriptor requests when they feel like it.
How can they distinguish? Not implemented for now, maybe
should abandon.
- - update dir-spec with what we decided for each of these
+ - describe our 302 not modified behaviors.
+ - and document a bit more -- e.g. it looks like we return an empty
+ 200 OK when somebody asks us for a networkstatus and we don't
+ have it?
-Things we'd like to do in 0.2.0.x:
- Proposals:
. 101: Voting on the Tor Directory System (plus 103)
o Prepare ASAP for new voting formats
@@ -210,15 +212,11 @@
- Write a proposal
- Bridges users (rudimentary version)
o Ability to specify bridges manually
- - cache of bridges that we've learned about and use but aren't
- manually listed in the torrc.
- D and some mechanism for specifying that we want to stop using
- a given bridge in this cache.
- . Config option 'UseBridges' that bridge users can turn on.
- - uses bridges as first hop rather than entry guards.
- D Do we want to maintain our own set of entryguards that we use
- after the bridge? Open research question; let's say no for 0.2.0
- unless we learn otherwise.
+ o Config option 'UseBridges' that bridge users can turn on.
+ o uses bridges as first hop rather than entry guards.
+ D Do we want to maintain our own set of entryguards that we use as
+ next hop after the bridge? Open research question; let's say no
+ for 0.2.0 unless we learn otherwise.
o if you don't have any routerinfos for your bridges, or you don't
like the ones you have, ask a new bridge for its server/authority.
. Ask all directory questions to bridge via BEGIN_DIR.
@@ -226,9 +224,13 @@
N - Design/implement the "local-status" or something like it, from the
"Descriptor purposes: how to tell them apart" section of
http://archives.seul.org/or/dev/May-2007/msg00008.html
+ - cache of bridges that we've learned about and use but aren't
+ manually listed in the torrc.
+ D and some mechanism for specifying that we want to stop using
+ a given bridge in this cache.
- timeout and retry schedules for fetching bridge descriptors
- give extend_info_t a router_purpose again
- - react faster to download networkstatuses after the first bridge
+ o react faster to download networkstatuses after the first bridge
descriptor arrives
- be more robust to bridges being marked as down and leaving us
stranded without any known "running" bridges.
@@ -238,6 +240,7 @@
- Fix BEGIN_DIR so that you connect to bridge of which you only
know IP (and optionally fingerprint), and then use BEGIN_DIR to learn
more about it.
+ - look at server_mode() and decide if it always applies to bridges too.
- Bridges authorities (rudimentary version)
o Rudimentary "do not publish networkstatus" option for bridge
authorities.
More information about the tor-commits
mailing list