[tor-dev] patch to torspec that seperates out the crypto.

Nick Mathewson nickm at alum.mit.edu
Thu Nov 3 23:22:59 UTC 2011


On Thu, Nov 3, 2011 at 6:30 PM, Watson Ladd <watsonbladd at gmail.com> wrote:
> Dear all,
> Here is a patch that removes crypto cruft from torspec.txt. It does
> make torspec unusable because we haven't written crypto.txt yet.
> In the process I noticed a few things I cleaned up, and also noticed
> that RELAY_EXTEND cells have to be understood by both ORs, which
> could be an impediment to migration.
> Sincerely,
> Watson Ladd

It's an interesting exercise but I don't think I can apply this any
time in the near future.

Trivial stuff that would be easy to fix:

a) It's an old-style diff. We're on unified diffs.  (So are most
open-source projects I know if.)

b) The clarity stuff is mixed in with the extract-crypto stuff. Like I
said previously, "It's best to do stuff like this in multiple small
steps if you want it merged upstream.  That way, if we like 80% of
what you're doing, we can merge the 8/10 pieces we like right away and
keep talking about the remaining 2/10."

c) It removes info without adding it elsewhere.  This would turn the
tor spec into "tor spec plus references to stuff that doesn't exist."
(I know you say "we haven't written it yet" -- but what's this "we"?
We already wrote a specification for Tor's crypto: it's tor-spec.txt.)

Fundamental stuff:

d) It feels like premature generalization.  The time to split off
"here is how the crypto fits in", it seems to me, is after we have
multiple crypto implementations.  Otherwise we're likely to draw the
boundaries wrong.

e) It adds confusing stuff in the name of clarity.  It's odd to say
that StreamIDs MUST NOT be zero and then go on to explain when they
may.

If you're having a good time and learning about Tor here I don't want
you to stop, but I don't think this is the right way to improve the
clarity and organization of our specifications.

apologies,
-- 
Nick


More information about the tor-dev mailing list