[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/main] fix some logic errors and typos in specs+proposals
commit 1850a1ebe730f206dd05557cf81461d9613c26b9
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
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
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits