[tor-commits] [torspec/master] Clean up copied section 3.6 and section 4.3.

[nickm at torproject.org]

commit c0e39f28b02bd247b20ecbe16750a475b06b876a
Author: Karsten Loesing <karsten.loesing at gmx.net>
Date:   Tue Jan 14 12:42:07 2014 +0100

    Clean up copied section 3.6 and section 4.3.
    
    Take out cache-only parts from 3.6 and authority-only parts from 4.3.
---
 dir-spec.txt |   49 ++++++++++++++++++-------------------------------
 1 file changed, 18 insertions(+), 31 deletions(-)

diff --git a/dir-spec.txt b/dir-spec.txt
index 4fc8fdd..0082443 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -1905,20 +1905,18 @@
 
 3.6. Downloading router descriptors
 
-   Periodically (currently, every 10 seconds), directory servers check
+   Periodically (currently, every 10 seconds), directory authorities check
    whether there are any specific descriptors that they do not have and that
-   they are not currently trying to download.  Caches identify these
-   descriptors by hash in the recent network-status consensus documents;
-   authorities identify them by hash in vote (if publication date is more
+   they are not currently trying to download.
+   Authorities identify them by hash in vote (if publication date is more
    recent than the descriptor we currently have).
 
  [XXXX need a way to fetch descriptors ahead of the vote?  v2 status docs can
  do that for now.]
 
-   If so, the directory server launches requests to the authorities for these
+   If so, the directory authority launches requests to the authorities for these
    descriptors, such that each authority is only asked for descriptors listed
-   in its most recent vote (if the requester is an authority) or in the
-   consensus (if the requester is a cache).  If we're an authority, and more
+   in its most recent vote.  If more
    than one authority lists the descriptor, we choose which to ask at random.
 
    If one of these downloads fails, we do not try to download that descriptor
@@ -1926,10 +1924,10 @@
    network-status (consensus or vote) from that authority that lists the same
    descriptor.
 
-   Directory servers must potentially cache multiple descriptors for each
-   router. Servers must not discard any descriptor listed by any recent
+   Directory authorities must potentially cache multiple descriptors for each
+   router. Authorities must not discard any descriptor listed by any recent
    consensus.  If there is enough space to store additional descriptors,
-   servers SHOULD try to hold those which clients are likely to download the
+   authorities SHOULD try to hold those which clients are likely to download the
    most.  (Currently, this is judged based on the interval for which each
    descriptor seemed newest.)
 [XXXX define recent]
@@ -2514,39 +2512,28 @@
    length.  Caches serve all consensus flavors from the same locations as
    the directory authorities.
 
-4.3. Downloading and storing router descriptors (authorities and caches)
+4.3. Downloading router descriptors
 
-   Periodically (currently, every 10 seconds), directory servers check
+   Periodically (currently, every 10 seconds), directory caches check
    whether there are any specific descriptors that they do not have and that
    they are not currently trying to download.  Caches identify these
-   descriptors by hash in the recent network-status consensus documents;
-   authorities identify them by hash in vote (if publication date is more
-   recent than the descriptor we currently have).
-
- [XXXX need a way to fetch descriptors ahead of the vote?  v2 status docs can
- do that for now.]
+   descriptors by hash in the recent network-status consensus documents.
 
-   If so, the directory server launches requests to the authorities for these
-   descriptors, such that each authority is only asked for descriptors listed
-   in its most recent vote (if the requester is an authority) or in the
-   consensus (if the requester is a cache).  If we're an authority, and more
-   than one authority lists the descriptor, we choose which to ask at random.
+   If so, the directory cache launches requests to the authorities for these
+   descriptors.
 
    If one of these downloads fails, we do not try to download that descriptor
    from the authority that failed to serve it again unless we receive a newer
-   network-status (consensus or vote) from that authority that lists the same
-   descriptor.
+   network-status consensus that lists the same descriptor.
 
-   Directory servers must potentially cache multiple descriptors for each
-   router. Servers must not discard any descriptor listed by any recent
+   Directory caches must potentially cache multiple descriptors for each
+   router. Caches must not discard any descriptor listed by any recent
    consensus.  If there is enough space to store additional descriptors,
-   servers SHOULD try to hold those which clients are likely to download the
+   caches SHOULD try to hold those which clients are likely to download the
    most.  (Currently, this is judged based on the interval for which each
    descriptor seemed newest.)
-[XXXX define recent]
 
-   Authorities SHOULD NOT download descriptors for routers that they would
-   immediately reject for reasons listed in section 3.2.
+   [XXXX define recent]
 
 4.4. Downloading and storing microdescriptors (caches only)