[tor-commits] [torspec/master] Fix references from moving section 4.1 to 3.2.
nickm at torproject.org
nickm at torproject.org
Fri Jan 17 15:45:15 UTC 2014
commit 6e5d367a290c7b84f78909e8f81cbaf8c1b39153
Author: Karsten Loesing <karsten.loesing at gmx.net>
Date: Mon Jan 13 19:58:15 2014 +0100
Fix references from moving section 4.1 to 3.2.
---
dir-spec.txt | 64 +++++++++++++++++++++++++++++-----------------------------
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/dir-spec.txt b/dir-spec.txt
index c6fe1c5..46d92fa 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -483,7 +483,7 @@
[At most once.]
- An exit-policy summary as specified in sections 3.3 and 3.5.2,
+ An exit-policy summary as specified in sections 3.4 and 3.6.2,
summarizing
the router's rules for connecting to IPv6 addresses. A missing
"ipv6-policy" line is equivalent to "ipv6-policy reject 1-65535".
@@ -1096,7 +1096,7 @@
Authorities MUST generate a new signing key and corresponding
certificate before the key expires.
-4.1. Accepting uploads (authorities only)
+3.2. Accepting uploads (authorities only)
When a router posts a signed descriptor to a directory authority, the
authority first checks whether it is well-formed and correctly
@@ -1131,7 +1131,7 @@
descriptor that it believes is currently useful. If so, it accepts it and
stores it and serves it as requested. If not, it drops it.
-3.2. Microdescriptors
+3.3. Microdescriptors
Microdescriptors are a stripped-down version of router descriptors
generated by the directory authorities which may additionally contain
@@ -1149,7 +1149,7 @@
contain any version information, because their version is determined
by the consensus method.
-3.2.1. Microdescriptors in consensus method 8 or later
+3.3.1. Microdescriptors in consensus method 8 or later
Starting with consensus method 8, microdescriptors contain the
following elements taken from or based on the router descriptor. Order
@@ -1188,7 +1188,7 @@
[At most once]
- The exit-policy summary as specified in sections 3.3 and 3.5.2. A
+ The exit-policy summary as specified in sections 3.4 and 3.6.2. A
missing "p" line is equivalent to "p reject 1-65535".
[With microdescriptors, clients don't learn exact exit policies:
@@ -1200,7 +1200,7 @@
[At most once]
- The IPv6 exit policy summary as specified in sections 3.3 and 3.5.2. A
+ The IPv6 exit policy summary as specified in sections 3.4 and 3.6.2. A
missing "p6" line is equivalent to "p6 reject 1-65535".
(Only included when generating microdescriptors for
@@ -1212,7 +1212,7 @@
they need to confirm the actual identity key when doing a TLS handshake,
and all they need to put the identity key digest in their CREATE cells.)
-3.3. Vote and consensus status documents
+3.4. Vote and consensus status documents
Votes and consensuses are more strictly formatted than other documents
in this specification, since different authorities must be able to
@@ -1252,7 +1252,7 @@
[At most once for votes; does not occur in consensuses.]
A space-separated list of supported methods for generating
- consensuses from votes. See section 3.5.1 for details. If this
+ consensuses from votes. See section 3.6.1 for details. If this
line is present, method "1" MUST be included. Absence of the
line means that only method "1" is supported.
@@ -1260,7 +1260,7 @@
[At most once for consensuses; does not occur in votes.]
- See section 3.5.1 for details.
+ See section 3.6.1 for details.
(Only included when the vote is generated with consensus-method 2 or
later.)
@@ -1689,7 +1689,7 @@
Wbe - Weight for Exit-flagged nodes for BEGIN_DIR requests
Wbd - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
- These values are calculated as specified in section 3.5.3.
+ These values are calculated as specified in section 3.6.3.
The signature contains the following item, which appears Exactly Once
for a vote, and At Least Once for a consensus.
@@ -1720,7 +1720,7 @@
(Tor clients before 0.2.3.x did not understand the 'algorithm'
field.)
-3.4. Assigning flags in a vote
+3.5. Assigning flags in a vote
(This section describes how directory authorities choose which status
flags to apply to routers. Later directory authorities MAY do things
@@ -1862,9 +1862,9 @@
accept not for all addresses, ignoring all rejects for private
netblocks. "Most" addresses are permitted if no more than 2^25
IPv4 addresses (two /8 networks) were blocked. The list is encoded
- as described in section 3.5.2.
+ as described in section 3.6.2.
-3.5. Computing a consensus from a set of votes
+3.6. Computing a consensus from a set of votes
Given a set of votes, authorities compute the contents of the consensus
document as follows:
@@ -1947,7 +1947,7 @@
for the descriptor we are listing. (They should all be the
same. If they are not, we pick the most commonly listed
one, breaking ties in favor of the lexicographically larger
- vote.) The port list is encoded as specified in section 3.5.2.
+ vote.) The port list is encoded as specified in section 3.6.2.
* If consensus-method 6 or later is in use and if 3 or more
authorities provide a Measured= keyword in their votes for
@@ -1991,7 +1991,7 @@
All ties in computing medians are broken in favor of the smaller or
earlier item.
-3.5.1. Forward compatibility
+3.6.1. Forward compatibility
Future versions of Tor will need to include new information in the
consensus documents, but it is important that all authorities (or at least
@@ -2029,7 +2029,7 @@
making changes in the contents of consensus; not for making
backward-incompatible changes in their format.)
-3.5.2. Encoding port lists
+3.6.2. Encoding port lists
Whether the summary shows the list of accepted ports or the list of
rejected ports depends on which list is shorter (has a shorter string
@@ -2049,7 +2049,7 @@
use an accept-style summary and list as much of the port list as is
possible within these 1000 bytes. [XXXX be more specific.]
-3.5.3. Computing Bandwidth Weights
+3.6.3. Computing Bandwidth Weights
Let weight_scale = 10000
@@ -2211,7 +2211,7 @@
Handle bridges and strange exit policies:
Wgm=Wgg, Wem=Wee, Weg=Wed
-3.6. Consensus flavors
+3.7. Consensus flavors
Consensus flavors are variants of the consensus that clients can choose
to download and use instead of the unflavored consensus. The purpose
@@ -2227,7 +2227,7 @@
Examples for consensus flavors include:
- Publishing hashes of microdescriptors instead of hashes of
- full descriptors (see section 3.6.2).
+ full descriptors (see section 3.7.2).
- Including different digests of descriptors, instead of the
perhaps-soon-to-be-totally-broken SHA1.
@@ -2248,7 +2248,7 @@
"network-status-version" SP version SP flavor NL
-3.6.1. ns consensus
+3.7.1. ns consensus
The ns consensus flavor is equivalent to the unflavored consensus
except for its first line which states its consensus flavor name:
@@ -2257,7 +2257,7 @@
[At start, exactly once.]
-3.6.2. Microdescriptor consensus
+3.7.2. Microdescriptor consensus
The microdescriptor consensus is a consensus flavor that contains
microdescriptor hashes instead of descriptor hashes and that omits
@@ -2283,7 +2283,7 @@
[At start, exactly once.]
- Similar to "r" lines in section 3.3, but without the digest element.
+ Similar to "r" lines in section 3.4, but without the digest element.
"p" ... NL
@@ -2313,7 +2313,7 @@
Additionally, a microdescriptor consensus MAY use the sha256 digest
algorithm for its signatures.
-3.7. Detached signatures
+3.8. Detached signatures
Assuming full connectivity, every authority should compute and sign the
same consensus including any flavors in each period. Therefore, it
@@ -2379,7 +2379,7 @@
All directory authorities and directory caches ("directory servers")
implement this section, except as noted.
-4.2. Voting (authorities only)
+4.1. Voting (authorities only)
Authorities divide time into Intervals. Authority administrators SHOULD
try to all pick the same interval length, and SHOULD pick intervals that
@@ -2453,7 +2453,7 @@
/tor/status-vote/(current|next)/consensus-F.z. and
/tor/status-vote/(current|next)/consensus-F/<FP1>+....z.
-4.3. Downloading consensus status documents (caches only)
+4.2. Downloading consensus status documents (caches only)
All directory servers (authorities and caches) try to keep a recent
network-status consensus document to serve to clients. A cache ALWAYS
@@ -2477,7 +2477,7 @@
length. Caches serve all consensus flavors from the same locations as
the directory authorities.
-4.4. Downloading and storing router descriptors (authorities and caches)
+4.3. Downloading and storing router descriptors (authorities and caches)
Periodically (currently, every 10 seconds), directory servers check
whether there are any specific descriptors that they do not have and that
@@ -2509,9 +2509,9 @@
[XXXX define recent]
Authorities SHOULD NOT download descriptors for routers that they would
- immediately reject for reasons listed in section 4.1.
+ immediately reject for reasons listed in section 3.2.
-4.5. Downloading and storing microdescriptors (caches only)
+4.4. Downloading and storing microdescriptors (caches only)
Directory mirrors should fetch, cache, and serve each microdescriptor
from the authorities.
@@ -2532,7 +2532,7 @@
(NOTE: Due to squid proxy url limitations at most 92 microdescrriptor hashes
can be retrieved in a single request.)
-4.6. Downloading and storing extra-info documents
+4.5. Downloading and storing extra-info documents
All authorities, and any cache that chooses to cache extra-info documents,
and any client that uses extra-info documents, should implement this
@@ -2546,9 +2546,9 @@
documents currently held. If so, it downloads whatever extra-info
documents are missing. Caches download from authorities; non-caches try
to download from caches. We follow the same splitting and back-off rules
- as in section 4.4 (if a cache) or section 5.3 (if a client).
+ as in section 4.3 (if a cache) or section 5.3 (if a client).
-4.7. General-use HTTP URLs
+4.6. General-use HTTP URLs
"Fingerprints" in these URLs are base16-encoded SHA1 hashes.
@@ -2791,7 +2791,7 @@
Everyone besides directory authorities uses the approaches in this section
to decide which relays to use and what their keys are likely to be.
- (Directory authorities just believe their own opinions, as in section 3.4
+ (Directory authorities just believe their own opinions, as in section 3.5
above.)
6.1. Choosing routers for circuits.
More information about the tor-commits
mailing list