[or-cvs] r9091: comments from the first pass through dir-voting. seems like (tor/trunk/doc)
arma at seul.org
arma at seul.org
Tue Dec 12 06:08:11 UTC 2006
Date: 2006-12-12 01:08:07 -0500 (Tue, 12 Dec 2006)
New Revision: 9091
comments from the first pass through dir-voting. seems like a fine
start, though we're going to have our hands full with edge cases when
the time comes.
--- tor/trunk/doc/dir-voting.txt 2006-12-12 05:45:19 UTC (rev 9090)
+++ tor/trunk/doc/dir-voting.txt 2006-12-12 06:08:07 UTC (rev 9091)
@@ -21,7 +21,7 @@
"most recent" networkstatus sources, and different versions of each
(since authorities change their statements often). Also, it is very
redundant: most of the downloaded networkstatus are probably quite
+ similar. Worse, the overhead grows as we add more authorities.
So if we have clients only download a single multiply signed consensus
network status statement, we can:
@@ -35,7 +35,7 @@
- Assuming that client-side or cache-side clocks are more correct
than we assume now.
- Assuming that authority clocks are perfectly correct.
- - Degrading badly if an authority dies or is offline for a bit.
+ - Degrading badly if a few authorities die or are offline for a bit.
We do not have to perform well if:
- No clique of more than half the authorities can agree about who
@@ -90,7 +90,10 @@
MUST match the nickname in the "directory-signature" entry.
"directory-signature" -- [XXXX this should be tagged with the nickname
- or identity somehow.]
+ or identity somehow. -NM] [The bottom of
+ http://belegost.mit.edu/tor/status/authority already puts the
+ nickname next to it. So we can just fix the spec to require
+ this? -RD]
Authorities SHOULD cache their most recently generated votes so they
can persist them across restarts. Authorities SHOULD NOT generate
@@ -124,9 +127,13 @@
re-English this sentence]
"client-versions" and "server-versions" are sorted in ascending
+ order based on version-spec.txt.
"dir-options" and "known-flags" are not included.
+[XXX really? why not list the ones that are used in the consensus?
+For example, right now BadExit is in use, but no servers would be
+labelled BadExit, and it's still worth knowing that it was considered
+by the authorities. -RD]
The fields MUST occur in the following order:
@@ -141,7 +148,7 @@
The signatures at the end of the document appear as multiple instances
- directory-signature, sorted in ascending order by nickname,
+ of directory-signature, sorted in ascending order by nickname,
A router entry should be included in the result if it is included by more
@@ -149,7 +156,12 @@
we have). A router entry has a flag set if it is included by more than
half of the authorities who care about that flag. [XXXX this creates an
incentive for attackers to DOS authorities whose votes they don't like.
- Can we remember what flags people set the last time we saw them?]
+ Can we remember what flags people set the last time we saw them? -NM]
+ [Which 'we' are we talking here? The end-users never learn which
+ authority sets which flags. So you're thinking the authorities
+ should record the last vote they saw from each authority and if it's
+ within a week or so, count all the flags that it advertised as 'no'
+ votes? Plausible. -RD]
The signature hash covers from the "network-status-version" line through
the characters "directory-signature" in the first "directory-signature"
@@ -227,6 +239,11 @@
another, we can rely on this existing mechanism to keep authorities up to
+ [We should do a thorough read-through of dir-spec again to make sure
+ that the authorities converge on which descriptor to "prefer" for
+ each router. Right now the decision happens at the client, which is
+ no longer the right place for it. -RD]
3. Questions and concerns
3.1. Push or pull?
More information about the tor-commits