[or-cvs] r9796: Oops; rename file for proposal 108. (in tor/trunk: . doc/spec/proposals)

[nickm@xxxxxxxx]

Author: nickm
Date: 2007-03-11 00:20:24 -0500 (Sun, 11 Mar 2007)
New Revision: 9796

Added:
   tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt
Removed:
   tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt
Modified:
   tor/trunk/
Log:
 r12528@Kushana:  nickm | 2007-03-11 00:19:05 -0500
 Oops; rename file for proposal 108.



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

Added: tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt
===================================================================
--- tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt	2007-03-10 14:54:12 UTC (rev 9795)
+++ tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt	2007-03-11 05:20:24 UTC (rev 9796)
@@ -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.

Deleted: tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt
===================================================================
--- tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt	2007-03-10 14:54:12 UTC (rev 9795)
+++ tor/trunk/doc/spec/proposals/108-mtbf-based-uptime.txt	2007-03-11 05:20:24 UTC (rev 9796)
@@ -1,42 +0,0 @@
-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.