remove/resolve several comments

svn:r724

doc/tor-design.tex

@@ -191,21 +191,6 @@ circuit building, users can notice failed
 nodes while building circuits and route around them.  Additionally,
 liveness information from directories allows users to avoid
 unreliable nodes in the first place.
-%We further provide a
-%simple mechanism that allows connections to be established despite recent
-%node failure or slightly dated information from a directory server. Tor
-%permits onion routers to have \emph{router twins}---nodes that share
-%the same private decryption key. Note that because connections now have
-%perfect forward secrecy, an onion router still cannot read the traffic
-%on a connection established through its twin even while that connection
-%is active. Also, which nodes are twins can change dynamically depending
-%on current circumstances, and twins may or may not be under the same
-%administrative authority.
-%
-%[Commented out; Router twins provide no real increase in robustness
-%to failed nodes.  If a non-twinned node goes down, the
-%circuit-builder notices this and routes around it.  Circuit-building
-%is offline, so there shouldn't even be a latency hit. -NM]
 
 \item \textbf{Variable exit policies:} Tor provides a consistent
 mechanism for
@@ -492,14 +477,6 @@ of network traffic; who can generate, modify, delete, or delay traffic
 on the network; who can operate onion routers of its own; and who can
 compromise some fraction of the onion routers on the network.
 
-%Large adversaries will be able to compromise a considerable fraction
-%of the network. (In some circumstances---for example, if the Tor
-%network is running on a hardened network where all operators have
-%had background checks---the number of compromised nodes could be quite
-%small.) Compromised nodes can arbitrarily manipulate the connections that
-%pass through them, as well as creating new connections that pass through
-%themselves.  They can observe traffic, and record it for later analysis.
-
 In low-latency anonymity systems that use layered encryption, the
 adversary's typical goal is to observe both the initiator and the
 receiver. Passive attackers can confirm a suspicion that Alice is
@@ -1105,7 +1082,6 @@ simplifying assumption that all participants agree on who the
 directory servers are. Second, Mixminion needs to predict node
 behavior, whereas Tor only needs a threshold consensus of the current
 state of the network.
-% Cite dir-spec or dir-agreement?
 
 Tor directory servers build a consensus directory through a simple
 four-round broadcast protocol.  In round one, each server dates and
@@ -1126,7 +1102,8 @@ signature is not included on the final directory.
 
 The rebroadcast steps ensure that a directory server is heard by
 either all of the other servers or none of them, assuming that any two
-directory servers can talk directly, or via a third directory server (some of the
+directory servers can talk directly, or via a third directory server
+(some of the
 links between directory servers may be down). Broadcasts are feasible
 because there are relatively few directory servers (currently 3, but we expect
 to transition to 9 as the network scales). The actual local algorithm
@@ -1150,8 +1127,6 @@ Thus directory servers are not a performance
 bottleneck when we have many users, and do not aid traffic analysis by
 forcing clients to periodically announce their existence to any
 central point.
-% Mention Hydra as an example of non-clique topologies. -NM, from RD
-
 
 \Section{Rendezvous points: location privacy}
 \label{sec:rendezvous}
@@ -1343,18 +1318,15 @@ and its resistance to attacks.
   outgoing TCP connections by drop-in libraries such as tsocks.
   
 \item[Flexibility:] Tor's design and implementation is fairly modular,
-  so that,
+  so that, for example, a scalable P2P replacement for the directory
-  for example, a scalable P2P replacement for the directory servers
+  servers would not substantially impact other aspects of the system.
-  would not substantially impact other aspects of the system.  Tor
+  Tor runs on top of TCP, so design options that could not easily do
-  runs on top of TCP, so design options that could not easily do so
+  so would be difficult to test on the current network. However, most
-  would be difficult to test on the current network. However, most
   low-latency protocols are designed to run over TCP. We are currently
-  discussing with the designers of MorphMix interoperability of the
+  working with the designers of MorphMix to render our two systems
-  two systems, which seems to be relatively straightforward. This will
+  interoperable. So for, this seems to be relatively straightforward.
-  allow testing and direct comparison of the two rather different
+  Interoperability will allow testing and direct comparison of the two
-  designs.
+  rather different designs.
-  % Do we want to say this?  I don't think we should talk about this
-  % kind of discussion till we have more positive results.
   
 \item[Simple design:] Tor opts for practicality when there is no
   clear resolution of anonymity tradeoffs or practical means to
@@ -1874,7 +1846,8 @@ a unified deployable system. But there are still several attacks that
 work quite well, as well as a number of sustainability and run-time
 issues remaining to be ironed out. In particular:
 
-% Many of these (Scalability, cover traffic) are duplicates from open problems.
+% Many of these (Scalability, cover traffic, morphmix) 
+% are duplicates from open problems.
 %
 \begin{tightlist}
 \item \emph{Scalability:} Tor's emphasis on design simplicity and
@@ -1919,10 +1892,10 @@ issues remaining to be ironed out. In particular:
   and development where we can start deploying a wider network.  Once
   we have are ready for actual users, we will doubtlessly be better
   able to evaluate some of our design decisions, including our
-  robustness/latency tradeoffs, our abuse-prevention mechanisms, and
+  robustness/latency tradeoffs, our performance trade-offs (including
+  cell size), our abuse-prevention mechanisms, and
   our overall usability.
 % XXX work with morphmix spec
-% XXX small cells vs large cells
 \end{tightlist}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%