[or-cvs] r9794: a few tweaks, plus actually close 107 (tor/trunk/doc/spec/proposals)

[arma@xxxxxxxx]

Author: arma
Date: 2007-03-10 03:13:34 -0500 (Sat, 10 Mar 2007)
New Revision: 9794

Modified:
   tor/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt
Log:
a few tweaks, plus actually close 107


Modified: tor/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt
===================================================================
--- tor/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt	2007-03-10 07:39:23 UTC (rev 9793)
+++ tor/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt	2007-03-10 08:13:34 UTC (rev 9794)
@@ -4,12 +4,12 @@
 Last-Modified:
 Author: Kevin Bauer & Damon McCoy
 Created: 8-March-2007
-Status: Open
+Status: Closed
 
 Overview:
 
    This document describes how to cap the uptime that is used when computing
-   which routers are maked as stable such that highly stable routers cannot
+   which routers are marked as stable such that highly stable routers cannot
    be displaced by malicious routers that report extremely high uptime
    values.
 
@@ -33,7 +33,7 @@
    "Stable" -- A router is 'Stable' if it is running, valid, not
    hibernating, and either its uptime is at least the median uptime for
    known running, valid, non-hibernating routers, or its uptime is at
-   least one month. Routers are never called stable if they are running
+   least 30 days. Routers are never called stable if they are running
    a version of Tor known to drop circuits stupidly.  (0.1.1.10-alpha
    through 0.1.1.16-rc are stupid this way.)
 
@@ -47,8 +47,9 @@
 
 Discussion:
 
-   Initially, this proposal set the maximum at 50 days, not 30; the 30 day
+   Initially, this proposal set the maximum at 60 days, not 30; the 30 day
    limit and spec wording was suggested by Roger in an or-dev post on 9 March
    2007.
 
    This proposal also led to 108-mtbf-based-stability.txt
+