Plan for proposal 104 (was: New system for modifying Tor protocol)

[Roger Dingledine <arma@xxxxxxx>]

On Tue, Mar 06, 2007 at 05:06:50PM -0500, Nick Mathewson wrote:
> Future big changes to Tor will follow this process, unless Roger and I
> screw up (which is, alas, always a possibility).  Discussion of
> proposals should take place on this list.

Time for discussion on proposal 104, which will hopefully be an easy
enough proposal to get us used to this 'discussing proposals' business. :)

For those of you who haven't already read it, go look at
http://tor.eff.org/svn/trunk/doc/spec/proposals/104-short-descriptors.txt

Solution 4 seems like a nice plan: in many cases, the external services
that use read-history and write-history are directory authorities
themselves, so they just use their local opinion.

I think we should go with the long/short descriptor plan, along
with solution 4. We don't want to just upload a bandwidth message,
because that involves new data structures for every new piece of
information we decide to upload. I suspect we'll realize once this
is deployed that there is other info we want to put in the long
descriptors.

This won't solve the future sanitized GeoIP uploading question, but
who knows where we'll actually want to send that data, and whether
we'll want to handle it with the same privacy constraints as this data,
so let's not try to solve that yet.

However, we may still need some basic reconciling algorithms between
authorities -- otherwise, if a router uploads to four authorities
and fails to reach the fifth, then that fifth will never have the new
descriptor. This will mean that the best strategy for external tools
is to fetch full concatenated-style long-descriptor lists from every
single authority, and merge them locally. So each authority should
periodically fetch the list from the others and take the new ones.

Is that it? Are there other pitfalls I'm missing? Are there better
options?

--Roger