When to add flags to network status vs adding new items

[Roger Dingledine]

On Sat, Dec 16, 2006 at 09:03:17PM -0500, Nick Mathewson wrote:
> > Both of these would be fine with me in this case. What's the right habit
> > down the road? Should we add new flags whenever there's a new capability,
> > or should we reserve flags for situations where the judgement is more
> > complex than a call to tor_version_as_new_as()?
> 
> I'd like to reserve flags for things deduced by the authorities, and
> include the first part of the platform string (i.e., "Tor
> 0.1.2.4-alpha") in the networkstatus for each router.

Sounds good to me. Where in particular should we put it?

>   Since we're
> planning to reduce networkstatus traffic in the next series with
> voting consensus directories, I think adding a platform string would
> be pretty darned safe...

Ok.

> ...but is this really something we should be using version numbers
> for?  It would be way cleaner to use numbered versions of the
> protocol for this, so that other implementations don't need to pretend
> to be a given version in order to be compatible.

Are we talking one version to describe everything, and we increment it
every time we add a new feature? If so, that pretty much forces other
implementations to build things in the same order we did. Or if we're
talking a bunch of different version numbers for each subsystem, how do
we decide which subsystems to version, and how do we avoid bloating the
networkstatus with O(n) version numbers?

Fortunately, we can get away with just using Tor version numbers for now,
since we're the only existing server implementation of the Tor protocol.
I vote that we stick with the easy answer for now, and if we need to get
more complex later then at least we'll know more about our constraints
at that point.

(Though I could be talked into sticking a "0" somewhere on the theory
that we'll be glad later that we did.)

--Roger