[tor-commits] [torspec/main] fix some logic errors and typos in specs+proposals

arma at torproject.org arma at torproject.org
Wed Jun 23 08:37:41 UTC 2021


commit 1850a1ebe730f206dd05557cf81461d9613c26b9
Author: Roger Dingledine <arma at torproject.org>
Date:   Wed Jun 23 04:35:49 2021 -0400

    fix some logic errors and typos in specs+proposals
---
 control-spec.txt                          |  2 +-
 proposals/196-transport-control-ports.txt |  2 +-
 proposals/217-ext-orport-auth.txt         |  4 ++--
 proposals/328-relay-overload-report.md    | 10 +++++-----
 proposals/329-traffic-splitting.txt       |  8 ++++----
 rend-spec-v3.txt                          |  6 +++---
 6 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/control-spec.txt b/control-spec.txt
index eac5f92..70f9b20 100644
--- a/control-spec.txt
+++ b/control-spec.txt
@@ -1044,7 +1044,7 @@
       return either a sequence of newline-terminated hex encoded digests, or
       a "serialized download status" as follows:
 
-       SerializedDownloadSatus =
+       SerializedDownloadStatus =
          -- when do we plan to next attempt to download this object?
          "next-attempt-at" SP ISOTime CRLF
          -- how many times have we failed since the last success?
diff --git a/proposals/196-transport-control-ports.txt b/proposals/196-transport-control-ports.txt
index afe6f11..15a1c02 100644
--- a/proposals/196-transport-control-ports.txt
+++ b/proposals/196-transport-control-ports.txt
@@ -196,7 +196,7 @@ Implemented-In: 0.2.5.2-alpha
 
 5. Authentication
 
-  To defend against cross-protocol attacks on the Extended ORPOrt,
+  To defend against cross-protocol attacks on the Extended ORPort,
   proposal 213 defines an authentication scheme that should be used to
   protect it.
 
diff --git a/proposals/217-ext-orport-auth.txt b/proposals/217-ext-orport-auth.txt
index 1305276..e453ec4 100644
--- a/proposals/217-ext-orport-auth.txt
+++ b/proposals/217-ext-orport-auth.txt
@@ -131,7 +131,7 @@ Target: 0.2.5.x
         "ExtORPort authentication server-to-client hash" | ClientNonce | ServerNonce)
   + ServerNonce is 32 random octets.
 
-  Upon receiving that data, the client computers ServerHash herself and
+  Upon receiving that data, the client computes ServerHash herself and
   validates it against the ServerHash provided by the server.
 
   If the server-provided ServerHash is invalid, the client MUST
@@ -146,7 +146,7 @@ Target: 0.2.5.x
       HMAC-SHA256(CookieString,
         "ExtORPort authentication client-to-server hash" | ClientNonce | ServerNonce)
 
-  Upon receiving that data, the server computers ClientHash herself and
+  Upon receiving that data, the server computes ClientHash herself and
   validates it against the ClientHash provided by the client.
 
   Finally, the server replies with:
diff --git a/proposals/328-relay-overload-report.md b/proposals/328-relay-overload-report.md
index 1ce2bc9..8bcbaa3 100644
--- a/proposals/328-relay-overload-report.md
+++ b/proposals/328-relay-overload-report.md
@@ -26,9 +26,9 @@ We propose that relays start collecting several metrics (see section 2)
 reflecting their loads from different component of tor.
 
 Then, we propose that 3 new lines be added to the extra-info document (see
-dir-spec.txt, section 2.1.2) if only the overload case arrise.
+dir-spec.txt, section 2.1.2) if only the overload case arises.
 
-This following describes a series of metrics to collect but more might come in
+The following describes a series of metrics to collect but more might come in
 the future and thus this is not an exhaustive list.
 
 # 1.1. General Overload
@@ -44,14 +44,14 @@ state" which can be one or many of the following load metrics:
    - Control port overload (too many messages queued)
 
 The format of the overloaded line added in the extra-info document is as
-follow:
+follows:
 
 ```
 "overload-general" SP version SP YYYY-MM-DD HH:MM:SS NL
    [At most once.]
 ```
 
-The timestamp is when at least one metrics was detected. It should always be
+The timestamp is when at least one metric was detected. It should always be
 at the hour and thus, as an example, "2020-01-10 13:00:00" is an expected
 timestamp. Because this is a binary state, if the line is present, we consider
 that it was hit at the very least once somewhere between the provided
@@ -87,7 +87,7 @@ and BandwidthBurst found in the torrc configuration file.
 
 The "{read|write}-overload-count" are the counts of how many times the reported
 limits of burst/rate were exhausted and thus the maximum between the read and
-write count occurances. To make the counter more meaningful and to avoid
+write count occurrences. To make the counter more meaningful and to avoid
 multiple connections saturating the counter when a relay is overloaded, we only
 increment it once a minute.
 
diff --git a/proposals/329-traffic-splitting.txt b/proposals/329-traffic-splitting.txt
index 292f51c..85d704b 100644
--- a/proposals/329-traffic-splitting.txt
+++ b/proposals/329-traffic-splitting.txt
@@ -22,7 +22,7 @@ Status: Draft
   
   The design space is broken into two orthogonal parts: congestion control
   algorithms that apply to each path, and traffic scheduling algorithms
-  that decide when to send packets to send on each path.
+  that decide which packets to send on each path.
   
   MPTCP specifies 'coupled' congestion control (see [COUPLED]). Coupled
   congestion control updates single-path congestion control algorithms to
@@ -32,10 +32,10 @@ Status: Draft
   accomplishing this have been proposed and implemented in the Linux
   kernel.
   
-  Because Tor's congestion control only concerns itself with bottnecks in
+  Because Tor's congestion control only concerns itself with bottlenecks in
   Tor relay queues, and not with any other bottlenecks (such as
   intermediate Internet routers), we can avoid this complexity merely by
-  specifying that any paths that are constructed SHOULD share any
+  specifying that any paths that are constructed SHOULD NOT share any
   relays. In this way, we can proceed to use the exact same congestion
   control as specified in Proposal 324, for each path.
   
@@ -465,7 +465,7 @@ Status: Draft
   
   XXX: Note that BLEST uses total_send_window where we use secondary.cwnd
   in this check. total_send_window is min(recv_win, CWND). But since Tor
-  does not use receive windows and intead uses stream XON/XOFF, we only
+  does not use receive windows and instead uses stream XON/XOFF, we only
   use CWND. There is some concern this may alter BLEST's buffer
   minimization properties, but since receive window only matter if
   the application is slower than Tor, and XON/XOFF will cover that case,
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt
index 83c3bdc..2abc732 100644
--- a/rend-spec-v3.txt
+++ b/rend-spec-v3.txt
@@ -350,7 +350,7 @@ Table of contents:
      Alex Biryukov,
      Lasse Øverlier,
      Ivan Pustogarov,
-     Paul Syverson
+     Paul Syverson,
      Ralf-Philipp Weinmann,
 
    See [ATTACK-REFS] for their papers.
@@ -364,7 +364,7 @@ Table of contents:
    And if this document makes any sense at all, it's thanks to
    editing help from
 
-      Matthew Finkel
+      Matthew Finkel,
       George Kadianakis,
       Peter Palfrader,
       Tim Wilson-Brown ("teor"),
@@ -2144,7 +2144,7 @@ Table of contents:
 
      where:
        - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
-       - VERSION is an one byte version field (default value '\x03')
+       - VERSION is a one byte version field (default value '\x03')
        - ".onion checksum" is a constant string
        - CHECKSUM is truncated to two bytes before inserting it in onion_address
 



More information about the tor-commits mailing list