| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091 | 
							- 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.
 
 
  |