[tor-commits] [torspec/master] Mark proposal 110 closed at last

nickm at torproject.org nickm at torproject.org
Tue Jan 17 16:06:51 UTC 2012


commit e036f2d2b1b533615ebf343d8c1cb2ab9bbd6507
Author: Nick Mathewson <nickm at torproject.org>
Date:   Tue Jan 17 11:09:05 2012 -0500

    Mark proposal 110 closed at last
---
 proposals/000-index.txt                   |    4 ++--
 proposals/110-avoid-infinite-circuits.txt |    4 ++--
 tor-spec.txt                              |    6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 92669b9..1457498 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -30,7 +30,7 @@ Proposals by number:
 107  Uptime Sanity Checking [CLOSED]
 108  Base "Stable" Flag on Mean Time Between Failures [CLOSED]
 109  No more than one server per IP address [CLOSED]
-110  Avoiding infinite length circuits [ACCEPTED]
+110  Avoiding infinite length circuits [CLOSED]
 111  Prioritizing local traffic over relayed traffic [CLOSED]
 112  Bring Back Pathlen Coin Weight [SUPERSEDED]
 113  Simplifying directory authority administration [SUPERSEDED]
@@ -148,7 +148,6 @@ Proposals by status:
    191  Bridge Detection Resistance against MITM-capable Adversaries
    192  Automatically retrieve and store information about bridges [for 0.2.[45].x]
  ACCEPTED:
-   110  Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha]
    117  IPv6 exits [for 0.2.3.x]
    140  Provide diffs between consensuses
    147  Eliminate the need for v2 directories in generating v3 directories [for 0.2.3.x]
@@ -178,6 +177,7 @@ Proposals by status:
    107  Uptime Sanity Checking [in 0.2.0.x]
    108  Base "Stable" Flag on Mean Time Between Failures [in 0.2.0.x]
    109  No more than one server per IP address [in 0.2.0.x]
+   110  Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha, 0.2.3.11-alpha]
    111  Prioritizing local traffic over relayed traffic [in 0.2.0.x]
    114  Distributed Storage for Tor Hidden Service Descriptors [in 0.2.0.x]
    119  New PROTOCOLINFO command for controllers [in 0.2.0.x]
diff --git a/proposals/110-avoid-infinite-circuits.txt b/proposals/110-avoid-infinite-circuits.txt
index 5da3261..7d6772d 100644
--- a/proposals/110-avoid-infinite-circuits.txt
+++ b/proposals/110-avoid-infinite-circuits.txt
@@ -2,9 +2,9 @@ Filename: 110-avoid-infinite-circuits.txt
 Title: Avoiding infinite length circuits
 Author: Roger Dingledine
 Created: 13-Mar-2007
-Status: Accepted
+Status: Closed
 Target: 0.2.3.x
-Implemented-In: 0.2.1.3-alpha
+Implemented-In: 0.2.1.3-alpha, 0.2.3.11-alpha
 
 History:
 
diff --git a/tor-spec.txt b/tor-spec.txt
index fea3073..7443644 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -895,7 +895,7 @@ see tor-design.pdf.
    A RELAY_EARLY cell is designed to limit the length any circuit can reach.
    When an OR receives a RELAY_EARLY cell, and the next node in the circuit
    is speaking v2 of the link protocol or later, the OR relays the cell as a
-   RELAY_EARLY cell.  Otherwise, it relays it as a RELAY cell.
+   RELAY_EARLY cell.  Otherwise, older Tors will relay it as a RELAY cell.
 
    If a node ever receives more than 8 RELAY_EARLY cells on a given
    outbound circuit, it SHOULD close the circuit. (For historical reasons,
@@ -908,8 +908,8 @@ see tor-design.pdf.
    RELAY cells that are not targeted at the first hop of any circuit as
    RELAY_EARLY cells too, in order to partially conceal the circuit length.
 
-   [In a future version of Tor, relays will reject any EXTEND cell not
-   received in a RELAY_EARLY cell.  See proposal 110.]
+   [Starting with Tor 0.2.3.11-alpha, future version of Tor, relays should
+   reject any EXTEND cell not received in a RELAY_EARLY cell.]
 
 6. Application connections and stream management
 



More information about the tor-commits mailing list