router twins are long gone from tor. take them out of the spec.

also note two spec things that need more explanation.


svn:r5355

1 files changed, 4 insertions, 4 deletions

diff --git a/doc/tor-spec.txt b/doc/tor-spec.txt
index d26e83598..6f059bd8f 100644
--- a/doc/tor-spec.txt
+++ b/doc/tor-spec.txt
@@ -15,6 +15,7 @@ more information on why Tor acts as it does, see tor-design.pdf.
 TODO: (very soon)
       - REASON_CONNECTFAILED should include an IP.
       - Copy prose from tor-design to make everything more readable.
+when do we rotate which keys (tls, link, etc)?
 
 0. Notation:
 
@@ -189,6 +190,9 @@ TODO: (very soon)
    The port and address field denote the IPV4 address and port of the next
    onion router in the circuit; the public key hash is the SHA1 hash of the
    PKCS#1 ASN1 encoding of the next onion router's identity (signing) key.
+[XXX please describe why we have this hash. my first guess is that this
+way we can notice that we're already connected to this guy even if he's
+connected at a different place. anything else? -RD]
 
    The payload for a CREATED cell, or the relay payload for an
    EXTENDED cell, contains:
@@ -315,10 +319,6 @@ TODO: (very soon)
    section 4.1. above, concerning choosing circIDs based on
    lexicographic order of nicknames.)
 
-   As an extension (called router twins), if the desired next onion
-   router R in the circuit is down, and some other onion router R'
-   has the same public keys as R, then it's ok to extend to R' rather than R.
-
    When an onion router receives a CREATE cell, if it already has a
    circuit on the given connection with the given circID, it drops the
    cell.  Otherwise, after receiving the CREATE cell, it completes the