r12202@Kushana: nickm | 2007-02-09 12:05:53 -0500

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]

      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.

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.

Last-Modified: $Date$

Author: Marc Liberatore

Created:

Status: Needs-Revision

Status: Dead

Overview: