[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [torspec/master] Make 3.5 and 3.6 subsections of 3.4.



commit fc17048ec0328459d872f48d6048e740107b6e77
Author: Karsten Loesing <karsten.loesing@xxxxxxx>
Date:   Tue Jan 14 11:25:34 2014 +0100

    Make 3.5 and 3.6 subsections of 3.4.
    
    The vote status document format (3.5) and the process of assigning flags
    in a vote (3.6) are both part of the authority operation "exchanging
    votes" and not operations on their own.  That's why they should be
    subsubsections rather than subsections.
    
    This results in the following changes to section numbers:
     * 3.5 -> 3.4.1
     * 3.6 -> 3.4.2
     * 3.7 -> 3.5
     * 3.8 -> 3.6
     * 3.9 -> 3.7
---
 dir-spec.txt |   42 +++++++++++++++++++++---------------------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/dir-spec.txt b/dir-spec.txt
index 44b8d4e..94570a9 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.5 and 3.7.2,
+       An exit-policy summary as specified in sections 3.4.1 and 3.5.2,
        summarizing
        the router's rules for connecting to IPv6 addresses. A missing
        "ipv6-policy" line is equivalent to "ipv6-policy reject 1-65535".
@@ -1186,7 +1186,7 @@
 
         [At most once]
 
-        The exit-policy summary as specified in sections 3.5 and 3.7.2.  A
+        The exit-policy summary as specified in sections 3.4.1 and 3.5.2.  A
         missing "p" line is equivalent to "p reject 1-65535".
 
         [With microdescriptors, clients don't learn exact exit policies:
@@ -1198,7 +1198,7 @@
 
         [At most once]
 
-        The IPv6 exit policy summary as specified in sections 3.5 and 3.7.2. A
+        The IPv6 exit policy summary as specified in sections 3.4.1 and 3.5.2. A
         missing "p6" line is equivalent to "p6 reject 1-65535".
 
         (Only included when generating microdescriptors for
@@ -1248,7 +1248,7 @@
       http://<hostname>/tor/status-vote/next/d/<d>.z
    where <d> is the digest of the vote document.
 
-3.5. Vote and consensus status documents
+3.4.1. Vote and consensus status document formats
 
    Votes and consensuses are more strictly formatted than other documents
    in this specification, since different authorities must be able to
@@ -1288,7 +1288,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.7.1 for details.  If this
+        consensuses from votes.  See section 3.5.1 for details.  If this
         line is present, method "1" MUST be included.  Absence of the
         line means that only method "1" is supported.
 
@@ -1296,7 +1296,7 @@
 
         [At most once for consensuses; does not occur in votes.]
 
-        See section 3.7.1 for details.
+        See section 3.5.1 for details.
 
         (Only included when the vote is generated with consensus-method 2 or
         later.)
@@ -1725,7 +1725,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.7.3.
+       These values are calculated as specified in section 3.5.3.
 
    The signature contains the following item, which appears Exactly Once
    for a vote, and At Least Once for a consensus.
@@ -1756,7 +1756,7 @@
         (Tor clients before 0.2.3.x did not understand the 'algorithm'
         field.)
 
-3.6. Assigning flags in a vote
+3.4.2. 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
@@ -1898,9 +1898,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.7.2.
+   as described in section 3.5.2.
 
-3.7. Computing a consensus from a set of votes
+3.5. Computing a consensus from a set of votes
 
    Given a set of votes, authorities compute the contents of the consensus
    document as follows:
@@ -1983,7 +1983,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.7.2.
+          vote.)  The port list is encoded as specified in section 3.5.2.
 
         * If consensus-method 6 or later is in use and if 3 or more
           authorities provide a Measured= keyword in their votes for
@@ -2027,7 +2027,7 @@
    All ties in computing medians are broken in favor of the smaller or
    earlier item.
 
-3.7.1. Forward compatibility
+3.5.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
@@ -2065,7 +2065,7 @@
    making changes in the contents of consensus; not for making
    backward-incompatible changes in their format.)
 
-3.7.2. Encoding port lists
+3.5.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
@@ -2085,7 +2085,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.7.3. Computing Bandwidth Weights
+3.5.3. Computing Bandwidth Weights
 
   Let weight_scale = 10000
 
@@ -2247,7 +2247,7 @@
   Handle bridges and strange exit policies:
      Wgm=Wgg, Wem=Wee, Weg=Wed
 
-3.8. Consensus flavors
+3.6. Consensus flavors
 
    Consensus flavors are variants of the consensus that clients can choose
    to download and use instead of the unflavored consensus.  The purpose
@@ -2263,7 +2263,7 @@
 
    Examples for consensus flavors include:
       - Publishing hashes of microdescriptors instead of hashes of
-        full descriptors (see section 3.8.2).
+        full descriptors (see section 3.6.2).
       - Including different digests of descriptors, instead of the
         perhaps-soon-to-be-totally-broken SHA1.
 
@@ -2284,7 +2284,7 @@
 
       "network-status-version" SP version SP flavor NL
 
-3.8.1. ns consensus
+3.6.1. ns consensus
 
    The ns consensus flavor is equivalent to the unflavored consensus
    except for its first line which states its consensus flavor name:
@@ -2293,7 +2293,7 @@
 
         [At start, exactly once.]
 
-3.8.2. Microdescriptor consensus
+3.6.2. Microdescriptor consensus
 
    The microdescriptor consensus is a consensus flavor that contains
    microdescriptor hashes instead of descriptor hashes and that omits
@@ -2319,7 +2319,7 @@
 
         [At start, exactly once.]
 
-        Similar to "r" lines in section 3.5, but without the digest element.
+        Similar to "r" lines in section 3.4.1, but without the digest element.
 
     "p" ... NL
 
@@ -2349,7 +2349,7 @@
    Additionally, a microdescriptor consensus MAY use the sha256 digest
    algorithm for its signatures.
 
-3.9. Detached signatures
+3.7. Detached signatures
 
    Assuming full connectivity, every authority should compute and sign the
    same consensus including any flavors in each period.  Therefore, it
@@ -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.6
+   (Directory authorities just believe their own opinions, as in section 3.4.2
    above.)
 
 6.1. Choosing routers for circuits.



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits