path-spec: reorganize selection rules a bit to clarify flow.

1 files changed, 33 insertions, 26 deletions

diff --git a/spec/path-spec/path-selection-constraints.md b/spec/path-spec/path-selection-constraints.md
index 7dac609..7905466 100644
--- a/spec/path-spec/path-selection-constraints.md
+++ b/spec/path-spec/path-selection-constraints.md
@@ -10,7 +10,11 @@ directory authorities use their own opinions.)
 We choose the
 exit node first, followed by the other nodes in the circuit, front to
 back. (In other words, for a 3-hop circuit, we first pick hop 3,
-then hop 1, then hop 2.)  All paths we generate obey the following
+then hop 1, then hop 2.)
+
+## Universal constraints
+
+All paths we generate obey the following
 constraints:
 
 - We do not choose the same router twice for the same path.
@@ -26,9 +30,31 @@ constraints:
   [guard specification](../guard-spec)).
 - XXXX Choosing the length
 
+## Special-purpose constraints
+
+Additionally, we may be building circuits with one or more requests in
+mind.  Each kind of request puts certain constraints on paths.
+
+Most circuits need to be "Fast".
+For these, we only choose nodes with the `Fast` flag.
+For non-"fast" circuits, nodes without the `Fast` flag are eligible.
 
-For "fast" circuits, we only choose nodes with the Fast flag. For
-non-"fast" circuits, all nodes are eligible.
+- TODO document which circuits (do not) need to be Fast.
+
+Similarly, some circuits need to be "Stable".
+For these, we only choose nodes with the Stable flag.
+
+- All service-side introduction circuits and all rendezvous paths
+  should be Stable.
+- All connection requests for connections that we think will need to
+  stay open a long time require Stable circuits.  Currently, Tor decides
+  this by examining the request's target port, and comparing it to a
+  list of "long-lived" ports. (Default: 21, 22, 706, 1863, 5050,
+  5190, 5222, 5223, 6667, 6697, 8300.)
+
+<a id="path-spec.txt-2.2.1"></a>
+
+## Weighting node selection
 
 For all circuits, we weight node selection according to router bandwidth.
 
@@ -72,35 +98,16 @@ If any of those weights is malformed or not present in a consensus,
 clients proceed with the regular path selection algorithm setting
 the weights to the default value of 10000.
 
-Additionally, we may be building circuits with one or more requests in
-mind.  Each kind of request puts certain constraints on paths:
-
-```text
-     - All service-side introduction circuits and all rendezvous paths
-       should be Stable.
-     - All connection requests for connections that we think will need to
-       stay open a long time require Stable circuits.  Currently, Tor decides
-       this by examining the request's target port, and comparing it to a
-       list of "long-lived" ports. (Default: 21, 22, 706, 1863, 5050,
-       5190, 5222, 5223, 6667, 6697, 8300.)
-     - DNS resolves require an exit node whose exit policy is not equivalent
-       to "reject *:*".
-     - Reverse DNS resolves require a version of Tor with advertised eventdns
-       support (available in Tor 0.1.2.1-alpha-dev and later).
-     - All connection requests require an exit node whose exit policy
-       supports their target address and port (if known), or which "might
-       support it" (if the address isn't known).  See 2.2.1.
-     - Rules for Fast? XXXXX
-```
-
-<a id="path-spec.txt-2.2.1"></a>
 
 ## Choosing an exit
 
-If we know what IP address we want to connect to or resolve, we can
+If we know what IP address we want to connect to, we can
 trivially tell whether a given router will support it by simulating
 its declared exit policy.
 
+(DNS resolve requests are only sent to relays whose
+exit policy is not equivalent to "reject *:*".)
+
 Because we often connect to addresses of the form hostname:port, we do not
 always know the target IP address when we select an exit node.  In these
 cases, we need to pick an exit node that "might support" connections to a