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