commit 686aaf110551c6d586f069e3ae6f8be6820bce8d Author: Isis Lovecruft isis@torproject.org Date: Wed Dec 13 23:52:15 2017 +0000

Typo fixes in prop#249, prop#276, and prop#279. --- proposals/249-large-create-cells.txt | 2 +- proposals/276-lower-bw-granularity.txt | 2 +- proposals/279-naming-layer-api.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index c08b596..54516be 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -146,7 +146,7 @@ Status: Open before it's needed, we can use the new handshake types whenever both of the involved relays support this proposal.

- Clients MUST NOT sent fragmented EXTEND2 cells to relays that don't + Clients MUST NOT send fragmented EXTEND2 cells to relays that don't support them, since this would cause them to close the circuit.

Relays MAY send CREATE2V and CREATED2V cells to relays that don't diff --git a/proposals/276-lower-bw-granularity.txt b/proposals/276-lower-bw-granularity.txt index bca544b..021aed8 100644 --- a/proposals/276-lower-bw-granularity.txt +++ b/proposals/276-lower-bw-granularity.txt @@ -69,6 +69,6 @@ Target: 0.3.1.x-alpha results?

Is there any reason to think this amount of smoothing would not - be save? + be safe?

Would a time-aware smoothing mechanism work better? diff --git a/proposals/279-naming-layer-api.txt b/proposals/279-naming-layer-api.txt index 9f8c104..13cbcbc 100644 --- a/proposals/279-naming-layer-api.txt +++ b/proposals/279-naming-layer-api.txt @@ -53,7 +53,7 @@ Status: Draft idnxcnkne4qt76tg.onion vwakviie2ienjx6t.onion

- When Proposal 224 get deployed, onion addresses will become even + When Proposal 224 gets deployed, onion addresses will become even bigger: 53 base32 characters. That's:

llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle.onion