1 files changed, 0 insertions, 85 deletions
diff --git a/doc/spec/proposals/120-shutdown-descriptors.txt b/doc/spec/proposals/120-shutdown-descriptors.txt
deleted file mode 100644
index dc1265b03b..0000000000
--- a/doc/spec/proposals/120-shutdown-descriptors.txt
+++ /dev/null
@@ -1,85 +0,0 @@
-Filename: 120-shutdown-descriptors.txt
-Title: Shutdown descriptors when Tor servers stop
-Version: $Revision$
-Last-Modified: $Date$
-Author: Roger Dingledine
-Created: 15-Aug-2007
-Status: Dead
-
-[Proposal dead as of 11 Jul 2008. The point of this proposal was to give
-routers a good way to get out of the networkstatus early, but proposal
-138 (already implemented) has achieved this.]
-
-Overview:
-
-  Tor servers should publish a last descriptor whenever they shut down,
-  to let others know that they are no longer offering service.
-
-The Problem:
-
-  The main reason for this is in reaction to Internet services that want
-  to treat connections from the Tor network differently. Right now,
-  if a user experiments with turning on the "relay" functionality, he
-  is punished by being locked out of some websites, some IRC networks,
-  etc --- and this lockout persists for several days even after he turns
-  the server off.
-
-Design:
-
-  During the "slow shutdown" period if exiting, or shortly after the
-  user sets his ORPort back to 0 if not exiting, Tor should publish a
-  final descriptor with the following characteristics:
-
-  1) Exit policy is listed as "reject *:*"
-  2) It includes a new entry called "opt shutdown 1"
-
-  The first step is so current blacklists will no longer list this node
-  as exiting to whatever the service is.
-
-  The second step is so directory authorities can avoid wasting time
-  doing reachability testing. Authorities should automatically not list
-  as Running any router whose latest descriptor says it shut down.
-
-  [I originally had in mind a third step --- Advertised bandwidth capacity
-  is listed as "0" --- so current Tor clients will skip over this node
-  when building most circuits. But since clients won't fetch descriptors
-  from nodes not listed as Running, this step seems pointless. -RD]
-
-Spec:
-
-  TBD but should be pretty straightforward.
-
-Security issues:
-
-  Now external people can learn exactly when a node stopped offering
-  relay service. How bad is this? I can see a few minor attacks based
-  on this knowledge, but on the other hand as it is we don't really take
-  any steps to keep this information secret.
-
-Overhead issues:
-
-  We are creating more descriptors that want to be remembered. However,
-  since the router won't be marked as Running, ordinary clients won't
-  fetch the shutdown descriptors. Caches will, though. I hope this is ok.
-
-Implementation:
-
-  To make things easy, we should publish the shutdown descriptor only
-  on controlled shutdown (SIGINT as opposed to SIGTERM). That would
-  leave enough time for publishing that we probably wouldn't need any
-  extra synchronization code.
-
-  If that turns out to be too unintuitive for users, I could imagine doing
-  it on SIGTERMs too, and just delaying exit until we had successfully
-  published to at least one authority, at which point we'd hope that it
-  propagated from there.
-
-Acknowledgements:
-
-  tup suggested this idea.
-
-Comments:
-
-  2) Maybe add a rule "Don't do this for hibernation if we expect to wake
-     up before the next consensus is published"?
-                                                      - NM 9 Oct 2007