mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 04:13:28 +01:00
some proposal fixes, mostly cosmetic
svn:r9551
This commit is contained in:
parent
ee67ab8ee9
commit
a1c8055131
@ -8,7 +8,7 @@ Status: Meta
|
||||
|
||||
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 @@ Proposals by number:
|
||||
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]
|
||||
|
@ -25,7 +25,7 @@ Motivation:
|
||||
|
||||
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 @@ How to change the specs now:
|
||||
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 @@ What should go in a proposal:
|
||||
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 @@ What should go in a proposal:
|
||||
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 @@ What should go in a proposal:
|
||||
|
||||
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
|
||||
|
@ -39,6 +39,9 @@ Any time:
|
||||
- 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 @@ B.2. ... and that we have no idea how to do.
|
||||
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.
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
Filename: 100-tor-spec-udp.txt
|
||||
Filename: 099-misc.txt
|
||||
Title: Miscellaneous proposals
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
|
@ -395,7 +395,7 @@ What changes need to happen to each node's exit policy to support this? -RD
|
||||
|
||||
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
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user