From d3f839d82c2e517eafb8f610004181302e3a3d20 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 21 Dec 2006 02:59:15 +0000 Subject: [PATCH] r11664@Kushana: nickm | 2006-12-20 21:58:54 -0500 Clarify some points in dir-voting.txt raised by Paul Syverson. svn:r9167 --- doc/dir-voting.txt | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/doc/dir-voting.txt b/doc/dir-voting.txt index ac0110fbf3..5f3157a9f0 100644 --- a/doc/dir-voting.txt +++ b/doc/dir-voting.txt @@ -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:///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:///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:///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:///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".