164-reporting-server-status.txt 2.8 KB

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