fix some logic errors and typos in specs+proposals

4 files changed, 12 insertions, 12 deletions

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,