diff options
| -rw-r--r-- | doc/spec/proposals/000-index.txt | 20 | ||||
| -rw-r--r-- | doc/spec/proposals/001-process.txt | 56 | ||||
| -rw-r--r-- | doc/spec/proposals/100-tor-spec-udp.txt | 2 |
3 files changed, 63 insertions, 15 deletions
diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index 08fc45a82..3b3fa03cc 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -14,14 +14,14 @@ Overview: Proposals by number: -000 Index of Tor Proposals -001 The Tor Proposal Process -098 Proposals that should be written -099 Miscellaneous proposals -100 Tor Unreliable Datagram Extension Proposal -101 Voting on the Tor Directory System. -102 Droping "opt" from the directory format -103 Splitting identity key from regularly used signing key. -104 Long and Short Router Descriptors -105 Version negotiation for the Tor protocol +000 Index of Tor Proposals [META] +001 The Tor Proposal Process [META] +098 Proposals that should be written [META] +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] +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] diff --git a/doc/spec/proposals/001-process.txt b/doc/spec/proposals/001-process.txt index 882a67924..418a5b853 100644 --- a/doc/spec/proposals/001-process.txt +++ b/doc/spec/proposals/001-process.txt @@ -82,7 +82,8 @@ Proposal status: See comments in the document for details. Dead: The proposal hasn't been touched in a long time, and it doesn't look - like anybody is going to complete it soon. + like anybody is going to complete it soon. It can become "Open" again + if it gets a new proponent. Needs-Research: There are research problems that need to be solved before it's clear whether the proposal is a good idea. @@ -96,7 +97,54 @@ Proposal numbering: What should go in a proposal: - WRITE MORE. + Every proposal should have a header containing these fields: + Filename, Title, Version, Last-Modified, Author, Created, Status. + The Version and Last-Modified fields should use the SVN Revision and Date + tags respectively. + + 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 + 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. + + Motivation: What problem is the proposal trying to solve? Why does + this problem matter? If several approaches are possible, why take this + one? + + Design: A high-level view of what the new or modified features are, how + the new or modified features work, how they interoperate with each + other, and how they interact with the rest of Tor. This is the main + body of the proposal. Some proposals will start out with only a + 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 + anonymity, how well understood these effects are, and so on. + + Specification: A detailed description of what needs to be added to the + Tor specifications in order to implement the proposal. This should + be in about as much detail as the specifications will eventually + contain: it should be possible for independent programmers to write + mutually compatible implementations of the proposal based on its + specifications. + + 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?] + + Implementation: If the proposal will be tricky to implement in Tor's + current architecture, the document can contain some discussion of how + to go about making it work. + + Performance and scalability notes: If the feature will have an effect + on performance (in RAM, CPU, bandwidth) or scalability, there should + be some analysis on how significant this effect will be, so that we + can avoid really expensive performance regressions, and so we can + avoid wasting time on insignificant gains. - Before a proposal is "ACCEPTED", it should have about as much detail as - the specs would for the proposed feature. diff --git a/doc/spec/proposals/100-tor-spec-udp.txt b/doc/spec/proposals/100-tor-spec-udp.txt index 31b894833..84be1bbf1 100644 --- a/doc/spec/proposals/100-tor-spec-udp.txt +++ b/doc/spec/proposals/100-tor-spec-udp.txt @@ -4,7 +4,7 @@ Version: $Revision$ Last-Modified: $Date$ Author: Marc Liberatore Created: -Status: Needs-Revision +Status: Dead Overview: |