[tor-commits] [torspec] branch main updated: fix some easy typos in proposals

[gitolite role <git@xxxxxxxxxxxxxxxxxxxxx>]

This is an automated email from the git hooks/post-receive script.

arma pushed a commit to branch main
in repository torspec.

The following commit(s) were added to refs/heads/main by this push:
     new b5e2002  fix some easy typos in proposals
b5e2002 is described below

commit b5e2002983fc4682b88fedb73a9101cc8090b053
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
AuthorDate: Wed Jul 27 01:25:09 2022 -0400

    fix some easy typos in proposals
---
 proposals/326-tor-relay-well-known-uri-rfc8615.md | 2 +-
 proposals/327-pow-over-intro.txt                  | 4 ++--
 proposals/341-better-oos.md                       | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/proposals/326-tor-relay-well-known-uri-rfc8615.md b/proposals/326-tor-relay-well-known-uri-rfc8615.md
index 7648162..075aa6d 100644
--- a/proposals/326-tor-relay-well-known-uri-rfc8615.md
+++ b/proposals/326-tor-relay-well-known-uri-rfc8615.md
@@ -12,7 +12,7 @@ This is a specification for a well-known [registry](https://www.iana.org/assignm
 
 This resource identifier can be used for serving and finding proofs related to [Tor](https://www.torproject.org/) relay and bridge contact information.
 It can also be used for autodiscovery of Tor relays run by a given entity, if the entity's domain is known.
-It solves the issue that Tor relay/bridge contact information is an unidirectional and unverified claim by nature.
+It solves the issue that Tor relay/bridge contact information is a unidirectional and unverified claim by nature.
 This well-known URI aims to allow the verification of the unidirectional claim.
 It aims to reduce the risk of impersonation attacks, where a Tor relay/bridge claims to be operated by a certain entity, but actually isn't.
 The automated verification will also support the [visualization of relay/bridge groups](https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001).
diff --git a/proposals/327-pow-over-intro.txt b/proposals/327-pow-over-intro.txt
index 0fb528f..ca7f7cd 100644
--- a/proposals/327-pow-over-intro.txt
+++ b/proposals/327-pow-over-intro.txt
@@ -339,7 +339,7 @@ Status: Draft
   tuple. For this reason a replay protection mechanism must be employed.
 
   The simplest way is to use a simple hash table to check whether a (seed,
-  nonce) tuple has been used before for the actiev duration of a
+  nonce) tuple has been used before for the active duration of a
   seed. Depending on how long a seed stays active this might be a viable
   solution with reasonable memory/time overhead.
 
@@ -439,7 +439,7 @@ Status: Draft
   Every HS_UPDATE_PERIOD seconds the service should upload a new descriptor
   with a new suggested-effort value.
 
-  The service should avoid uploading descriptors too often to avoid overwheming
+  The service should avoid uploading descriptors too often to avoid overwhelming
   the HSDirs. The service SHOULD NOT upload descriptors more often than
   HS_UPDATE_PERIOD. The service SHOULD NOT upload a new descriptor if the
   suggested-effort value changes by less than 15%.
diff --git a/proposals/341-better-oos.md b/proposals/341-better-oos.md
index 0715c14..8ddf7fd 100644
--- a/proposals/341-better-oos.md
+++ b/proposals/341-better-oos.md
@@ -56,7 +56,7 @@ other words, when you see "A - B" below, read it as "MAX(A-B, 0)".
 
 ## Phase 1: Deciding how many connections to close
 
-When we are find that we are low on sockets, we pick a number of sockets
+When we find that we are low on sockets, we pick a number of sockets
 that we want to close according to our existing algorithm.  (That is, we
 try to close 1/4 of our maximum sockets if we have reached our upper
 limit, or 1/10 of our maximum sockets if we have encountered a failure
@@ -133,8 +133,8 @@ until we have closed at least our target number of exit connections.
 > This approach probabilistically favors closing circuits with a large
 > number of sockets open, regardless of how long those sockets have been
 > open.  This defeats the easiest way of opening a large number of exit
-> streams ("open them all on once circuit") without making the
-> counter-approach ("open each exit stream on a its own circuit") much
+> streams ("open them all on one circuit") without making the
+> counter-approach ("open each exit stream on its own circuit") much
 > more attractive.
 
 ## Phase 3: Closing OR connections.

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits