proposals/164-reporting-server-status.txt

   1 Filename: 164-reporting-server-status.txt
   2 Title: Reporting the status of server votes
   3 Author: Nick Mathewson
   4 Created: 22-May-2009
   5 Status: Open
   6
   7
   8 Overview:
   9
  10    When a given node isn't listed in the directory, it isn't always easy
  11    to tell why.  This proposal suggest a quick-and-dirty way for
  12    authorities to export not only how they voted, but why, and a way to
  13    collate the information.
  14
  15 Motivation:
  16
  17    Right now, if you want to know the reason why your server was listed
  18    a certain way in the Tor directory, the following steps are
  19    recommended:
  20
  21        - Look through your log for reports of what the authority said
  22          when you tried to upload.
  23
  24        - Look at the consensus; see if you're listed.
  25
  26        - Wait a while, see if things get better.
  27
  28        - Download the votes from all the authorities, and see how they
  29          voted.  Try to figure out why.
  30
  31        - If you think they'll listen to you, ask some authority
  32          operators to look you up in their mtbf files and logs to see
  33          why they voted as they did.
  34
  35    This is far too hard.
  36
  37 Solution:
  38
  39    We should add a new vote-like information-only document that
  40    authorities serve on request.  Call it a "vote info".  It is
  41    generated at the same time as a vote, but used only for
  42    determining why a server voted as it did.  It is served from
  43    /tor/status-vote-info/current/authority[.z]
  44
  45    It differs from a vote in that:
  46
  47    * Its vote-status field is 'vote-info'.
  48
  49    * It includes routers that the authority would not include
  50      in its vote.
  51
  52      For these, it includes an "omitted" line with an English
  53      message explaining why they were omitted.
  54
  55    * For each router, it includes a line describing its WFU and
  56      MTBF.  The format is:
  57
  58        "stability <mtbf> up-since='date'"
  59        "uptime <wfu> down-since='date'"
  60
  61    * It describes the WFU and MTBF thresholds it requires to
  62      vote for a given router in various roles in the header.
  63      The format is:
  64
  65        "flag-requirement <flag-name> <field> <op> <value>"
  66
  67      e.g.
  68
  69        "flag-requirement Guard uptime > 80"
  70
  71    * It includes info on routers all of whose descriptors that
  72      were uploaded but rejected over the past few hours.  The
  73      "r" lines for these are the same as for regular routers.
  74      The other lines are omitted for these routers, and are
  75      replaced with a single "rejected" line, explaining (in
  76      English) why the router was rejected.
  77
  78
  79    A status site (like Torweather or Torstatus or another
  80    tool) can poll these files when they are generated, collate
  81    the data, and make it available to server operators.
  82
  83 Risks:
  84
  85    This document makes no provisions for caching these "vote
  86    info" documents.  If many people wind up fetching them
  87    aggressively from the authorities, that would be bad.
  88
  89
  90