1 files changed, 0 insertions, 84 deletions
diff --git a/doc/spec/proposals/118-multiple-orports.txt b/doc/spec/proposals/118-multiple-orports.txt
deleted file mode 100644
index 2381ec7ca..000000000
--- a/doc/spec/proposals/118-multiple-orports.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-Filename: 118-multiple-orports.txt
-Title: Advertising multiple ORPorts at once
-Author: Nick Mathewson
-Created: 09-Jul-2007
-Status: Accepted
-Target: 0.2.1.x
-
-Overview:
-
-   This document is a proposal for servers to advertise multiple
-   address/port combinations for their ORPort.
-
-Motivation:
-
-   Sometimes servers want to support multiple ports for incoming
-   connections, either in order to support multiple address families, to
-   better use multiple interfaces, or to support a variety of
-   FascistFirewallPorts settings.  This is easy to set up now, but
-   there's no way to advertise it to clients.
-
-New descriptor syntax:
-
-   We add a new line in the router descriptor, "or-address".  This line
-   can occur zero, one, or multiple times.  Its format is:
-
-      or-address SP ADDRESS ":" PORTLIST NL
-
-      ADDRESS = IP6ADDR / IP4ADDR
-      IPV6ADDR = an ipv6 address, surrounded by square brackets.
-      IPV4ADDR = an ipv4 address, represented as a dotted quad.
-      PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST
-      PORTSPEC = PORT | PORT "-" PORT
-
-   [This is the regular format for specifying sets of addresses and
-   ports in Tor.]
-
-New OR behavior:
-
-   We add two more options to supplement ORListenAddress:
-   ORPublishedListenAddress, and ORPublishAddressSet.  The former
-   listens on an address-port combination and publishes it in addition
-   to the regular address.  The latter advertises a set of address-port
-   combinations, but does not listen on them.  [To use this option, the
-   server operator should set up port forwarding to the regular ORPort,
-   as for example with firewall rules.]
-
-   Servers should extend their testing to include advertised addresses
-   and ports.  No address or port should be advertised until it's been
-   tested.  [This might get expensive in practice.]
-
-New authority behavior:
-
-   Authorities should spot-test descriptors, and reject any where a
-   substantial part of the addresses can't be reached.
-
-New client behavior:
-
-   When connecting to another server, clients SHOULD pick an
-   address-port ocmbination at random as supported by their
-   reachableaddresses.  If a client has a connection to a server at one
-   address, it SHOULD use that address for any simultaneous connections
-   to that server.  Clients SHOULD use the canonical address for any
-   server when generating extend cells.
-
-Not addressed here:
-
-   * There's no reason to listen on multiple dirports; current Tors
-   mostly don't connect directly to the dirport anyway.
-
-   * It could be advantageous to list something about extra addresses in
-   the network-status document.  This would, however, eat space there.
-   More analysis is needed, particularly in light of proposal 141
-   ("Download server descriptors on demand")
-
-Dependencies:
-
-   Testing for canonical connections needs to be implemented before it's
-   safe to use this proposal.
-
-
-Notes 3 July:
-  - Write up the simple version of this.  No ranges needed yet.  No
-    networkstatus chagnes yet.
-