[or-cvs] r9182: change the v2 dir spec to reflect how the code actually work (tor/trunk/doc)

[arma@xxxxxxxx]

Author: arma
Date: 2006-12-24 00:28:52 -0500 (Sun, 24 Dec 2006)
New Revision: 9182

Modified:
   tor/trunk/doc/dir-spec.txt
   tor/trunk/doc/dir-voting.txt
Log:
change the v2 dir spec to reflect how the code actually works
with respect to the directory-signature line.

this also resolves nick's issue with how to change the
directory-signature entry in votes. unless there's more to
it than that.


Modified: tor/trunk/doc/dir-spec.txt
===================================================================
--- tor/trunk/doc/dir-spec.txt	2006-12-24 04:09:48 UTC (rev 9181)
+++ tor/trunk/doc/dir-spec.txt	2006-12-24 05:28:52 UTC (rev 9182)
@@ -403,9 +403,11 @@
 
    The signature section contains:
 
-      "directory-signature". A signature of the rest of the document
+      "directory-signature" nickname-of-dirserver NL Signature
+
+      Signature is a signature of this network-status document
       (the document up until the signature, including the line
-      "directory-signature <nick>\n") using the directory authority's
+      "directory-signature <nick>\n"), using the directory authority's
       signing key.
 
    We compress the network status list with zlib before transmitting it.

Modified: tor/trunk/doc/dir-voting.txt
===================================================================
--- tor/trunk/doc/dir-voting.txt	2006-12-24 04:09:48 UTC (rev 9181)
+++ tor/trunk/doc/dir-voting.txt	2006-12-24 05:28:52 UTC (rev 9182)
@@ -19,10 +19,12 @@
 
   This creates a partitioning problem: different clients have different
   "most recent" networkstatus sources, and different versions of each
-  (since authorities change their statements often).  Also, it is very
-  redundant: most of the downloaded networkstatus are probably quite
-  similar.  Worse, the overhead grows as we add more authorities.
+  (since authorities change their statements often).
 
+  It also creates a scaling problem: most of the downloaded networkstatus
+  are probably quite similar, and the redundancy grows as we add more
+  authorities.
+
   So if we have clients only download a single multiply signed consensus
   network status statement, we can:
        - Save bandwidth.
@@ -65,10 +67,12 @@
   If an authority computes the vote wrong, its signature isn't included on
   the consensus.
 
-  Clients use a consensus if it is signed by more than half the
-  authorities they recognize.  If they can't find any such consensus,
-  clients either use an older version, or beg the user to adapt the list
-  of authorities.
+  Clients use a consensus if it is "trusted": signed by more than half the
+  authorities they recognize. If clients can't find any such consensus,
+  they use the most recent trusted consensus they have. If they don't
+  have any trusted consensus, they warn the user and refuse to operate
+  (and if DirServers is not the default, beg the user to adapt the list
+  of authorities).
 
 2. Details.
 
@@ -89,12 +93,6 @@
         authority's nickname, which MUST be unique among authorities, and
         MUST match the nickname in the "directory-signature" entry.
 
-     "directory-signature" -- [XXXX this should be tagged with the nickname
-        or identity somehow. -NM] [The bottom of
-        http://belegost.mit.edu/tor/status/authority already puts the
-        nickname next to it. So we can just fix the spec to require
-        this? -RD]
-
   Authorities SHOULD cache their most recently generated votes so they
   can persist them across restarts.  Authorities SHOULD NOT generate
   another document until valid-until has passed.