r16666@tombo: nickm | 2008-07-02 15:17:46 -0400

 Mark 145 and 146 open (oops).  Add new proposal 147 about making v2 directories less needed.


svn:r15607

4 files changed, 62 insertions, 6 deletions

diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt
index ff36f9976..e13b32c51 100644
--- a/doc/spec/proposals/000-index.txt
+++ b/doc/spec/proposals/000-index.txt
@@ -67,8 +67,9 @@ Proposals by number:
 142  Combine Introduction and Rendezvous Points [OPEN]
 143  Improvements of Distributed Storage for Tor Hidden Service Descriptors [OPEN]
 144  Increase the diversity of circuits by detecting nodes belonging the [DRAFT]
-145  Separate "suitable as a guard" from "suitable as a new guard" [DRAFT]
-146  Add new flag to reflect long-term stability [DRAFT]
+145  Separate "suitable as a guard" from "suitable as a new guard" [OPEN]
+146  Add new flag to reflect long-term stability [OPEN]
+147  Eliminate the need for v2 directories in generating v3 directories [OPEN]
 
 
 Proposals by status:
@@ -82,8 +83,6 @@ Proposals by status:
    134  More robust consensus voting with diverse authority sets
    141  Download server descriptors on demand
    144  Increase the diversity of circuits by detecting nodes belonging the
-   145  Separate "suitable as a guard" from "suitable as a new guard"
-   146  Add new flag to reflect long-term stability
  OPEN:
    120  Shutdown descriptors when Tor servers stop
    121  Hidden Service Authentication
@@ -91,6 +90,9 @@ Proposals by status:
    140  Provide diffs between consensuses
    142  Combine Introduction and Rendezvous Points
    143  Improvements of Distributed Storage for Tor Hidden Service Descriptors
+   145  Separate "suitable as a guard" from "suitable as a new guard"
+   146  Add new flag to reflect long-term stability
+   147  Eliminate the need for v2 directories in generating v3 directories
  NEEDS-REVISION:
    110  Avoiding infinite length circuits
    117  IPv6 exits
diff --git a/doc/spec/proposals/145-newguard-flag.txt b/doc/spec/proposals/145-newguard-flag.txt
index 04eff061b..6e901fc7f 100644
--- a/doc/spec/proposals/145-newguard-flag.txt
+++ b/doc/spec/proposals/145-newguard-flag.txt
@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Nick Mathewson
 Created: 1-Jul-2008
-Status: Draft
+Status: Open
 
 Overview
 
diff --git a/doc/spec/proposals/146-long-term-stability.txt b/doc/spec/proposals/146-long-term-stability.txt
index d92d5581d..66a373f19 100644
--- a/doc/spec/proposals/146-long-term-stability.txt
+++ b/doc/spec/proposals/146-long-term-stability.txt
@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Nick Mathewson
 Created: 19-Jun-2008
-Status: Draft
+Status: Open
 
 Overview
 
diff --git a/doc/spec/proposals/147-prevoting-opinions.txt b/doc/spec/proposals/147-prevoting-opinions.txt
new file mode 100644
index 000000000..db66d3e7c
--- /dev/null
+++ b/doc/spec/proposals/147-prevoting-opinions.txt
@@ -0,0 +1,54 @@
+Filename: 147-prevoting-opinions.txt
+Title: Eliminate the need for v2 directories in generating v3 directories
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Mathewson
+Created: 2-Jul-2008
+Status: Open
+
+Overview
+
+  We propose a new v3 vote document type to replace the role of v2
+  networkstatus information in generating v3 consensuses.
+
+Motivation
+
+  When authorities vote on which descriptors are to be listed in the
+  next consensus, it helps if they all know about the same descriptors
+  as one another.  But a hostile, confused, or out-of-date server may
+  upload a descriptor to only some authorities.  In the current v3
+  directory design, the authorities don't have a good way to tell one
+  another about the new descriptor until they exchange votes... but by
+  the time this happens, they are already committed to their votes,
+  and they can't add anybody they learn about from other authorities
+  until the next voting cycle.  That's no good!
+
+  The current Tor implementation avoids this problem by having
+  authorities also look at v2 networkstatus documents, but we'd like
+  in the long term to eliminate these, once 0.1.2.x is obsolete.
+
+Design:
+
+  We add a new value for vote-status in v3 consensus documents in
+  addition to "consensus" and "vote": "opinion".  Authorities generate
+  and sign an opinion document as if they were generating a vote,
+  except that they send it to one another earlier than they send
+  votes.
+
+  Authorities don't need to generate more than one opinion document
+  per voting interval, but may.  They should send it to the other
+  authorities they know about, at the regular vote upload URL, before
+  the authorities begin voting, so that enough time remains for the
+  authorities to fetch new descriptors.
+
+  Upon receiving an opinion document, authorities scan it for any
+  descriptors that:
+     - They might accept.
+     - Are for routers they don't know about, or are published more
+       recently than any descriptor they have for that router.
+  Authorities then begin downloading such descriptors from authorities
+  that claim to have them.
+
+  Authorities MAY cache opinion documents, but don't need to.
+
+