Short proposal on reporting why authorities voted as they did

2 files changed, 93 insertions, 0 deletions

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 8c8b0ab..26622e8 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -84,6 +84,7 @@ Proposals by number:
 161  Computing Bandwidth Adjustments [OPEN]
 162  Publish the consensus in multiple flavors [OPEN]
 163  Detecting whether a connection comes from a client [OPEN]
+164  Reporting the status of server votes [OPEN]
 
 
 Proposals by status:
@@ -109,6 +110,7 @@ Proposals by status:
    161  Computing Bandwidth Adjustments [for 0.2.2.x]
    162  Publish the consensus in multiple flavors [for 0.2.2]
    163  Detecting whether a connection comes from a client [for 0.2.2]
+   164  Reporting the status of server votes [for 0.2.2]
  ACCEPTED:
    110  Avoiding infinite length circuits [for 0.2.1.x] [in 0.2.1.3-alpha]
    117  IPv6 exits [for 0.2.1.x]
diff --git a/proposals/164-reporting-server-status.txt b/proposals/164-reporting-server-status.txt
new file mode 100644
index 0000000..705f5f1
--- /dev/null
+++ b/proposals/164-reporting-server-status.txt
@@ -0,0 +1,91 @@
+Filename: 164-reporting-server-status.txt
+Title: Reporting the status of server votes
+Author: Nick Mathewson
+Created: 22-May-2009
+Target: 0.2.2
+Status: Open
+
+
+Overview:
+
+   When a given node isn't listed in the directory, it isn't always easy
+   to tell why.  This proposal suggest a quick-and-dirty way for
+   authorities to export not only how they voted, but why, and a way to
+   collate the information.
+
+Motivation:
+
+   Right now, if you want to know the reason why your server was listed
+   a certain way in the Tor directory, the following steps are
+   recommended:
+
+       - Look through your log for reports of what the authority said
+         when you tried to upload.
+
+       - Look at the consensus; see if you're listed.
+
+       - Wait a while, see if things get better.
+
+       - Download the votes from all the authorities, and see how they
+         voted.  Try to figure out why.
+
+       - If you think they'll listen to you, ask some authority
+         operators to look you up in their mtbf files and logs to see
+         why they voted as they did.
+
+   This is far too hard.
+
+Solution:
+
+   We should add a new vote-like information-only document that
+   authorities serve on request.  Call it a "vote info".  It is
+   generated at the same time as a vote, but used only for
+   determining why a server voted as it did.  It is served from
+   /tor/status-vote-info/current/authority[.z]
+
+   It differs from a vote in that:
+
+   * Its vote-status field is 'vote-info'.
+
+   * It includes routers that the authority would not include
+     in its vote.
+
+     For these, it includes an "omitted" line with an English
+     message explaining why they were omitted.
+
+   * For each router, it includes a line describing its WFU and
+     MTBF.  The format is:
+
+       "stability <mtbf> up-since='date'"
+       "uptime <wfu> down-since='date'"
+
+   * It describes the WFU and MTBF thresholds it requires to
+     vote for a given router in various roles in the header.
+     The format is:
+
+       "flag-requirement <flag-name> <field> <op> <value>"
+
+     e.g.
+
+       "flag-requirement Guard uptime > 80"
+
+   * It includes info on routers all of whose descriptors that
+     were uploaded but rejected over the past few hours.  The
+     "r" lines for these are the same as for regular routers.
+     The other lines are omitted for these routers, and are
+     replaced with a single "rejected" line, explaining (in
+     English) why the router was rejected.
+
+
+   A status site (like Torweather or Torstatus or another
+   tool) can poll these files when they are generated, collate
+   the data, and make it available to server operators.
+
+Risks:
+
+   This document makes no provisions for caching these "vote
+   info" documents.  If many people wind up fetching them
+   aggressively from the authorities, that would be bad.
+
+
+