Skip to content
Snippets Groups Projects
Commit d3f839d8 authored by Nick Mathewson's avatar Nick Mathewson :game_die:
Browse files

r11664@Kushana: nickm | 2006-12-20 21:58:54 -0500

 Clarify some points in dir-voting.txt raised by Paul Syverson.


svn:r9167
parent b9baed40
Branches
Tags
No related merge requests found
......@@ -183,10 +183,10 @@ by the authorities. -RD]
2.3.1. URLs and timeline used for agreement
A router SHOULD publish its vote immediately at the start of each voting
An authority SHOULD publish its vote immediately at the start of each voting
period. It does this by making it available at
http://<hostname>/tor/status-vote/current/authority.z
and posting it to each other authority at the URL
and sending it in an HTTP POST request to each other authority at the URL
http://<hostname>/tor/post/vote
If, N minutes after the voting period has begun, an authority does not have
......@@ -206,7 +206,8 @@ by the authorities. -RD]
http://<hostname>/tor/status-vote/current/consensus-signatures.z
Once an authority has computed and signed a consensus network status, it
should send its detached signature to each other authority at the URL
should send its detached signature to each other authority in an HTTP POST
request to the URL:
http://<hostname>/tor/post/consensus-signature
......@@ -248,7 +249,11 @@ by the authorities. -RD]
3.1. Push or pull?
[XXXX]
The URLs above define a push mechanism for publishing votes and consensus
signatures via HTTP POST requests, and a pull mechanism for downloading
these documents via HTTP GET requests. As specified, every authority will
post to every other. The "download if no copy has been received" mechanism
exists only as a fallback.
3.2. Dropping "opt".
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment