Add short IDs for most long section names

I've left off sections that are headings for their whole document.

3 files changed, 20 insertions, 20 deletions

diff --git a/spec/guard-spec/algorithm.md b/spec/guard-spec/algorithm.md
index b18803b..832814a 100644
--- a/spec/guard-spec/algorithm.md
+++ b/spec/guard-spec/algorithm.md
@@ -4,7 +4,7 @@
 
 <a id="guard-spec.txt-4.0"></a>
 
-## The guards listed in the current consensus. \[Section:GUARDS\]
+## The guards listed in the current consensus. {#GUARDS}
 
 By {set:GUARDS} we mean the set of all guards in the current
 consensus that are usable for all circuits and directory
@@ -17,7 +17,7 @@ from any guard, so that all guards are usable for all circuits.
 
 <a id="guard-spec.txt-4.1"></a>
 
-## The Sampled Guard Set. \[Section:SAMPLED\]
+## The Sampled Guard Set. {#SAMPLED}
 
 We maintain a set, {set:SAMPLED_GUARDS}, that persists across
 invocations of Tor. It is a subset of the nodes ordered by a sample idx that
@@ -130,7 +130,7 @@ adversary node.
 
 <a id="guard-spec.txt-4.2"></a>
 
-## The Usable Sample \[Section:FILTERED\]
+## The Usable Sample {#FILTERED}
 
 We maintain another set, {set:FILTERED_GUARDS}, that does not
 persist. It is derived from:
@@ -185,7 +185,7 @@ filtering restrictions that we had in the past.
 
 <a id="guard-spec.txt-4.3"></a>
 
-## The confirmed-guard list. \[Section:CONFIRMED\]
+## The confirmed-guard list. {#CONFIRMED}
 
 \[formerly USED_GUARDS\]
 
@@ -247,7 +247,7 @@ traffic.
 
 <a id="guard-spec.txt-4.4"></a>
 
-## The Primary guards \[Section:PRIMARY\]
+## The Primary guards {#PRIMARY}
 
 We keep a run-time non-persistent ordered list of
 {list:PRIMARY_GUARDS}.  It is a subset of {FILTERED_GUARDS}.  It
@@ -280,7 +280,7 @@ usable after all.
 
 <a id="guard-spec.txt-4.5"></a>
 
-## Retrying guards. \[Section:RETRYING\]
+## Retrying guards. {#RETRYING}
 
 (We run this process as frequently as needed. It can be done once
 a second, or just-in-time.)
@@ -410,7 +410,7 @@ sure that it's the best guard we're getting. (see below).
 
 <a id="guard-spec.txt-4.7"></a>
 
-## When a circuit fails. \[Section:ON_FAIL\]
+## When a circuit fails. {#ON_FAIL}
 
 When a circuit fails in a way that makes us conclude that a guard
 is not reachable, we take the following steps:
@@ -437,7 +437,7 @@ See \[SELECTING\] above for rationale.
 
 <a id="guard-spec.txt-4.8"></a>
 
-## When a circuit succeeds \[Section:ON_SUCCESS\]
+## When a circuit succeeds {#ON_SUCCESS}
 
 When a circuit succeeds in a way that makes us conclude that a
 guard _was_ reachable, we take these steps:
@@ -476,7 +476,7 @@ See \[SELECTING\] above for rationale.
 
 <a id="guard-spec.txt-4.9"></a>
 
-## Updating the list of waiting circuits \[Section:UPDATE_WAITING\]
+## Updating the list of waiting circuits {#UPDATE_WAITING}
 
 We run this procedure whenever it's possible that a
 `<waiting_for_better_guard>` circuit might be ready to be called
@@ -516,7 +516,7 @@ them after all if the `<complete>` circuit goes down before
 
 <a id="guard-spec.txt-4.9.1"></a>
 
-### Without a list of waiting circuits \[Section:NO_CIRCLIST\]
+### Without a list of waiting circuits {#NO_CIRCLIST}
 
 As an alternative to the section \[SECTION:UPDATE_WAITING\] above,
 this section presents a new way to maintain guard status
@@ -559,7 +559,7 @@ these rules:
 
 <a id="guard-spec.txt-4.10"></a>
 
-## Whenever we get a new consensus. \[Section:ON_CONSENSUS\]
+## Whenever we get a new consensus. {#ON_CONSENSUS}
 
 We update {GUARDS}.
 
diff --git a/spec/guard-spec/appendices.md b/spec/guard-spec/appendices.md
index 34368ad..2eacc62 100644
--- a/spec/guard-spec/appendices.md
+++ b/spec/guard-spec/appendices.md
@@ -11,7 +11,7 @@ CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548.
 
 <a id="guard-spec.txt-A.1"></a>
 
-## Parameters with suggested values. \[Section:PARAM_VALS\]
+## Parameters with suggested values. {#PARAM_VALS}
 
 (All suggested values chosen arbitrarily)
 
@@ -80,7 +80,7 @@ CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548.
 
 <a id="guard-spec.txt-A.2"></a>
 
-## Random values \[Section:RANDOM\]
+## Random values {#RANDOM}
 
 Frequently, we want to randomize the expiration time of something
 so that it's not easy for an observer to match it to its start
@@ -92,7 +92,7 @@ the past, chosen uniformly at random.
 
 <a id="guard-spec.txt-A.3"></a>
 
-## Why not a sliding scale of primaryness? \[Section:CVP\]
+## Why not a sliding scale of primaryness? {#CVP}
 
 At one meeting, I floated the idea of having "primaryness" be a
 continuous variable rather than a boolean.
@@ -157,7 +157,7 @@ become built too.
 
 <a id="guard-spec.txt-A.5"></a>
 
-## Persistent state format
+## Persistent state format {#persistent-state}
 
 The persistent state format doesn't need to be part of this
 specification, since different implementations can do it
diff --git a/spec/guard-spec/guard-selection-intro.md b/spec/guard-spec/guard-selection-intro.md
index b31609f..c3738d4 100644
--- a/spec/guard-spec/guard-selection-intro.md
+++ b/spec/guard-spec/guard-selection-intro.md
@@ -1,6 +1,6 @@
 <a id="guard-spec.txt-3"></a>
 
-# Circuit Creation, Entry Guard Selection (1000 foot view)
+# Circuit Creation, Entry Guard Selection (1000 foot view) {#1000-foot}
 
 A circuit in Tor is a path through the network connecting a client to
 its destination. At a high-level, a three-hop exit circuit will look
@@ -12,7 +12,7 @@ Entry guards are the only nodes which a client will connect to
 directly. Exit relays are the nodes by which traffic exits the
 Tor network in order to connect to an external destination.
 
-3.1 Path selection
+## Path selection
 
 For any multi-hop circuit, at least one entry guard and middle node(s) are
 required. An exit node is required if traffic will exit the Tor
@@ -21,7 +21,7 @@ consensus could be used for any of these roles. However, this
 specification defines how entry guards specifically should be selected and
 managed, as opposed to middle or exit nodes.
 
-3.1.1 Managing entry guards
+### Managing entry guards
 
 At a high level, a relay listed in a consensus will move through the
 following states in the process from initial selection to eventual
@@ -52,14 +52,14 @@ It is always preferable to use a primary guard when building a new
 circuit in order to reduce guard churn; only on failure to connect to
 existing primary guards will new guards be used.
 
-3.1.2 Middle and exit node selection
+### Middle and exit node selection
 
 Middle nodes are selected at random from relays listed in the latest
 consensus, weighted by bandwidth and bandwidth-weights. Exit nodes are
 chosen similarly but restricted to relays with a sufficiently permissive
 exit policy.
 
-3.2 Circuit Building
+## Circuit Building
 
 Once a path is chosen, Tor will use this path to build a new circuit.