[or-cvs] r9793: Mark 107 closed (since it was implemented and merged into th (in tor/trunk: . doc/spec/proposals)

[nickm@xxxxxxxx]

Author: nickm
Date: 2007-03-10 02:39:23 -0500 (Sat, 10 Mar 2007)
New Revision: 9793

Added:
   tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt
Modified:
   tor/trunk/
   tor/trunk/doc/spec/proposals/000-index.txt
   tor/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt
Log:
 r12522@Kushana:  nickm | 2007-03-10 02:38:33 -0500
 Mark 107 closed (since it was implemented and merged into the spec). Put MTBF proposal in 108.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r12522] on c95137ef-5f19-0410-b913-86e773d04f59

Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt	2007-03-10 07:39:20 UTC (rev 9792)
+++ tor/trunk/doc/spec/proposals/000-index.txt	2007-03-10 07:39:23 UTC (rev 9793)
@@ -25,4 +25,5 @@
 104  Long and Short Router Descriptors [OPEN]
 105  Version negotiation for the Tor protocol [OPEN]
 106  Checking fewer things during TLS handshakes [CLOSED]
-107  Uptime Sanity Checking [OPEN]
+107  Uptime Sanity Checking [CLOSED]
+108  Base "Stable" Flag on Mean Time Between Failures [OPEN]

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:20 UTC (rev 9792)
+++ tor/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt	2007-03-10 07:39:23 UTC (rev 9793)
@@ -51,4 +51,4 @@
    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-uptime.txt
+   This proposal also led to 108-mtbf-based-stability.txt

Added: tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt
===================================================================
--- tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt	2007-03-10 07:39:20 UTC (rev 9792)
+++ tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt	2007-03-10 07:39:23 UTC (rev 9793)
@@ -0,0 +1,42 @@
+Filename: 108-mtbf-based-stability.txt
+Title: Base "Stable" Flag on Mean Time Between Failures
+Version: $Revision: 12105 $
+Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $
+Author: Nick Mathewson
+Created:
+Status: Open
+
+Overview:
+
+   This document proposes that we change how directory authorities set the
+   stability flag from inspection of routers declared Uptime to the
+   authorities' perceived mean time between failure for the router.
+
+Motivation:
+
+   Clients prefer nodes that the authorities call Stable.  This flags are (as
+   of 0.2.0.0-alpha-dev) set entirely based on the nodes' declared values for
+   uptime.  This creates an opportunity for malicious nodes to declare
+   falsely high uptimes in order to get more traffic.
+
+Spec changes:
+
+   Instead of setting the current rule for setting the Stable flag:
+
+   "An authority should call a server Stable if its observed MTBF for
+   the past month is at or above the median MTBF for Valid servers.
+
+   MTBF shall be defined as the mean length of the runs observed by a
+   given directory authority.  A run begins when an authority decides
+   that the server is Running, and ends when the authority decides that
+   the server is not Running.  In-progress runs are counted when
+   measuring MTBF."
+
+Issues:
+
+   How do you define a clipped MTBF?  If the current month begins with one
+   day at the end of a one-year uptime, and then has 29 days of uptime, do we
+   average one day and 29 days?  Or do we average one year and 29 days?  Or
+   take 29 days on its own and discard the year?
+
+   Surely somebody has done this kinds of thing before.