diff options
Diffstat (limited to 'spec/dir-spec/serving-bandwidth-list-files.md')
| -rw-r--r-- | spec/dir-spec/serving-bandwidth-list-files.md | 44 |
1 files changed, 22 insertions, 22 deletions
diff --git a/spec/dir-spec/serving-bandwidth-list-files.md b/spec/dir-spec/serving-bandwidth-list-files.md index 2dd5ff4..6b0296b 100644 --- a/spec/dir-spec/serving-bandwidth-list-files.md +++ b/spec/dir-spec/serving-bandwidth-list-files.md @@ -43,8 +43,8 @@ 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.] +\[XXXX need a way to fetch descriptors ahead of the vote? v2 status docs can +do that for now.\] If so, the directory authority launches requests to the authorities for these descriptors, such that each authority is only asked for descriptors listed @@ -455,7 +455,7 @@ Port lists are sorted in ascending order. The maximum allowed length of a policy summary (including the "accept " or "reject ") is 1000 characters. If a summary exceeds that length we use an accept-style summary and list as much of the port list as is -possible within these 1000 bytes. [XXXX be more specific.] +possible within these 1000 bytes. \[XXXX be more specific.\] <a id="dir-spec.txt-3.8.3"></a> @@ -526,7 +526,7 @@ Wed == 1/3. Let R denote the more scarce class (Rare) between Guard vs Exit. Let S denote the less scarce class. -Subcase a: R+D < S +Subcase a: R+D \< S In this subcase, we simply devote all of D bandwidth to the scarce class. @@ -544,15 +544,15 @@ scarce class. Subcase b: R+D >= S ``` -In this case, if M <= T/3, we have enough bandwidth to try to achieve +In this case, if M \<= T/3, we have enough bandwidth to try to achieve a balancing condition. Add constraints Wgg = weight_scale, Wmd == Wgd to maximize bandwidth in the guard position while still allowing exits to be used as middle nodes: -Wee = (weight_scale*(E - G + M))/E -Wed = (weight_scale*(D - 2*E + 4*G - 2*M))/(3*D) -Wme = (weight_scale*(G-M))/E +Wee = (weight_scale\*(E - G + M))/E +Wed = (weight_scale\*(D - 2*E + 4*G - 2*M))/(3*D) +Wme = (weight_scale\*(G-M))/E Wmg = 0 Wgg = weight_scale Wmd = (weight_scale - Wed)/2 @@ -680,7 +680,7 @@ All consensus flavors have in common that their first line is "network-status-version" where version is 3 or higher, and the flavor is a string consisting of alphanumeric characters and dashes: -"network-status-version" SP version [SP flavor] NL +"network-status-version" SP version \[SP flavor\] NL <a id="dir-spec.txt-3.9.1"></a> @@ -709,7 +709,7 @@ the exceptions as follows: "network-status-version" SP version SP "microdesc" NL -[At start, exactly once.] +\[At start, exactly once.\] The flavor name of a microdescriptor consensus is "microdesc". @@ -736,7 +736,7 @@ later.) "p" ... NL -[At most once] +\[At most once\] Not currently generated. @@ -745,7 +745,7 @@ therefore omitted in the microdescriptor consensus. "m" SP digest NL -[Exactly once.*] +\[Exactly once.\*\] "digest" is the base64 of the SHA256 hash of the router's microdescriptor with trailing =s omitted. For a given router @@ -758,8 +758,8 @@ consensus should contain whichever microdescriptor digest is most common. If there is no winner, we break ties in the favor of the lexically earliest. -[*Before consensus method 13, this field was sometimes erroneously -omitted.] +\[\*Before consensus method 13, this field was sometimes erroneously +omitted.\] Additionally, a microdescriptor consensus SHOULD use the sha256 digest algorithm for its signatures. @@ -774,7 +774,7 @@ request to the URL: `http://<hostname>/tor/post/consensus-signature` -[XXX Note why we support push-and-then-pull.] +\[XXX Note why we support push-and-then-pull.\] All of the detached signatures it knows for consensus status should be available at: @@ -790,7 +790,7 @@ follows: "consensus-digest" SP Digest NL -[At start, at most once.] +\[At start, at most once.\] The digest of the consensus being signed. @@ -798,11 +798,11 @@ The digest of the consensus being signed. "fresh-until" SP YYYY-MM-DD SP HH:MM:SS NL "valid-until" SP YYYY-MM-DD SP HH:MM:SS NL -[As in the consensus] +\[As in the consensus\] "additional-digest" SP flavor SP algname SP digest NL -[Any number.] +\[Any number.\] For each supported consensus flavor, every directory authority adds one or more "additional-digest" lines. "flavor" is the name @@ -834,13 +834,13 @@ the OAEP+-padded SHA256 digest of the item to be signed. When checking signatures, the signature MUST be treated as valid if the signature material begins with SHA256(document), so that other data can get added later. -[To be honest, I didn't fully understand the previous paragraph -and only copied it from the proposals. Review carefully. -KL] +\[To be honest, I didn't fully understand the previous paragraph +and only copied it from the proposals. Review carefully. -KL\] "directory-signature" -[As in the consensus; the signature object is the same as in the -consensus document.] +\[As in the consensus; the signature object is the same as in the +consensus document.\] <a id="dir-spec.txt-3.11"></a> |