[or-cvs] r9551: some proposal fixes, mostly cosmetic (tor/trunk/doc/spec/proposals)
arma at seul.org
arma at seul.org
Sat Feb 10 21:38:31 UTC 2007
Author: arma
Date: 2007-02-10 16:38:31 -0500 (Sat, 10 Feb 2007)
New Revision: 9551
Modified:
tor/trunk/doc/spec/proposals/000-index.txt
tor/trunk/doc/spec/proposals/001-process.txt
tor/trunk/doc/spec/proposals/098-todo.txt
tor/trunk/doc/spec/proposals/099-misc.txt
tor/trunk/doc/spec/proposals/100-tor-spec-udp.txt
tor/trunk/doc/spec/proposals/104-short-descriptors.txt
Log:
some proposal fixes, mostly cosmetic
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2007-02-10 21:26:36 UTC (rev 9550)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2007-02-10 21:38:31 UTC (rev 9551)
@@ -8,7 +8,7 @@
Overview:
- This document provides an index to closed and open Tor proposals.
+ This document provides an index to Tor proposals.
This is an informational document.
@@ -20,7 +20,7 @@
099 Miscellaneous proposals [META]
100 Tor Unreliable Datagram Extension Proposal [DEAD]
101 Voting on the Tor Directory System [OPEN]
-102 Droping "opt" from the directory format [CLOSED]
+102 Dropping "opt" from the directory format [CLOSED]
103 Splitting identity key from regularly used signing key [OPEN]
104 Long and Short Router Descriptors [OPEN]
105 Version negotiation for the Tor protocol [OPEN]
Modified: tor/trunk/doc/spec/proposals/001-process.txt
===================================================================
--- tor/trunk/doc/spec/proposals/001-process.txt 2007-02-10 21:26:36 UTC (rev 9550)
+++ tor/trunk/doc/spec/proposals/001-process.txt 2007-02-10 21:38:31 UTC (rev 9551)
@@ -25,7 +25,7 @@
First, even at its most efficient, the old process would often have the
spec out of sync with the code. The worst cases were those where
- implementation was deferred: the spec and could stay out of sync for
+ implementation was deferred: the spec and code could stay out of sync for
versions at a time.
Second, it was hard to participate in discussion, since you had to know
@@ -55,12 +55,12 @@
remain the canonical documentation for the Tor protocol: no proposal is
ever the canonical documentation for an implemented feature.
- {It's still okay to make mall changes to the spec if the code can be
+ {It's still okay to make small changes to the spec if the code can be
written more or less immediately, or cosmetic changes if no code change is
required. This document reflects the current developers' _intent_, not
a permanent promise to always use this process in the future: we reserve
the right to get really excited and run off and implement something in a
- caffeine-and-m&m-fueled all-night hacking session.}
+ caffeine-or-m&m-fueled all-night hacking session.}
Proposal status:
@@ -105,11 +105,11 @@
The body of the proposal should start with an Overview section explaining
what the proposal's about, what it does, and about what state it's in.
- After the Overview, the proposal becomes more free-form. Depending its
+ After the Overview, the proposal becomes more free-form. Depending on its
the length and complexity, the proposal can break into sections as
appropriate, or follow a short discursive format. Every proposal should
contain at least the following information before it can be "ACCEPTED",
- thought the information does not need to be in sections with these names.
+ though the information does not need to be in sections with these names.
Motivation: What problem is the proposal trying to solve? Why does
this problem matter? If several approaches are possible, why take this
@@ -122,7 +122,7 @@
Motivation and a Design, and wait for a specification until the
Design seems approximately right.
- Security implications: What effects might the proposed changes have on
+ Security implications: What effects the proposed changes might have on
anonymity, how well understood these effects are, and so on.
Specification: A detailed description of what needs to be added to the
@@ -134,9 +134,9 @@
Compatibility: Will versions of Tor that follow the proposal be
compatible with versions that do not? If so, how will compatibility
- me achieved? Generally, we try to not to drop compatibility if at
- all possible; we haven't made a "flag day" change since 2003 or
- earlier, and we don't want to do another one. [XXX is this true?]
+ be achieved? Generally, we try to not drop compatibility if at
+ all possible; we haven't made a "flag day" change since May 2004,
+ and we don't want to do another one.
Implementation: If the proposal will be tricky to implement in Tor's
current architecture, the document can contain some discussion of how
Modified: tor/trunk/doc/spec/proposals/098-todo.txt
===================================================================
--- tor/trunk/doc/spec/proposals/098-todo.txt 2007-02-10 21:26:36 UTC (rev 9550)
+++ tor/trunk/doc/spec/proposals/098-todo.txt 2007-02-10 21:38:31 UTC (rev 9551)
@@ -39,6 +39,9 @@
- Spec should incorporate some prose from tor-design to be more readable.
- Spec when we should rotate which keys
+ - We should use a variable-length path length by default -- 3 +/- some
+ distribution. Need to think harder about allowing values less than 3,
+ and there's a tradeoff between having a wide variance and performance.
Things that should change...
@@ -73,5 +76,6 @@
doesn't grow with the number of hops, is not patented, and
is implemented and maintained by smart people.
-Let onion keys be not just RSA but maybe DH too. for the reply onion
+Let onion keys be not just RSA but maybe DH too, for Paul's reply onion
design.
+
Modified: tor/trunk/doc/spec/proposals/099-misc.txt
===================================================================
--- tor/trunk/doc/spec/proposals/099-misc.txt 2007-02-10 21:26:36 UTC (rev 9550)
+++ tor/trunk/doc/spec/proposals/099-misc.txt 2007-02-10 21:38:31 UTC (rev 9551)
@@ -1,4 +1,4 @@
-Filename: 100-tor-spec-udp.txt
+Filename: 099-misc.txt
Title: Miscellaneous proposals
Version: $Revision$
Last-Modified: $Date$
Modified: tor/trunk/doc/spec/proposals/100-tor-spec-udp.txt
===================================================================
--- tor/trunk/doc/spec/proposals/100-tor-spec-udp.txt 2007-02-10 21:26:36 UTC (rev 9550)
+++ tor/trunk/doc/spec/proposals/100-tor-spec-udp.txt 2007-02-10 21:38:31 UTC (rev 9551)
@@ -395,7 +395,7 @@
Switching to UDP means managing the queues of incoming packets better,
so we don't miss packets. How does this interact with doing large public
-key operations (handshakes) in the same thread?
+key operations (handshakes) in the same thread? -RD
========================================================================
COMMENTS
Modified: tor/trunk/doc/spec/proposals/104-short-descriptors.txt
===================================================================
--- tor/trunk/doc/spec/proposals/104-short-descriptors.txt 2007-02-10 21:26:36 UTC (rev 9550)
+++ tor/trunk/doc/spec/proposals/104-short-descriptors.txt 2007-02-10 21:38:31 UTC (rev 9551)
@@ -1,5 +1,5 @@
Filename: 104-short-descriptors.txt
-Title: Long and Short Router Descriptors
+Title: Long and Short Router Descriptors
Version: $Revision$
Last-Modified: $Date$
Author: Nick Mathewson
More information about the tor-commits
mailing list