On Wed, Dec 09, 2020 at 10:09:51AM -0500, David Goulet wrote: > On 07 Dec (15:36:53), Ian Goldberg wrote: > > On Mon, Dec 07, 2020 at 03:06:43PM -0500, David Goulet wrote: > > > Greetings, > > > > > > Attached is a proposal from Mike Perry and I. Merge requsest is here: > > > > > > https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 > > > > > > Cheers! > > > David > > > > Nice! > > > > Is there a way to distinguish "not overloaded" from "does not support > > this extension"? (Ideally in a better way than checking the tor release > > version number and inferring when support was added?) > > Gooood point. > > So in theory, we have protocol version[1] in order to differentiate relays but > I do not believe such a change would be a wise thing to use a new "Desc=" > since tor will just ignore the unknown fields. > > The other reason for that is that "tor functionalities" as in to function > properly won't depend on that descriptor field so it is a bit a stretch to > justify this as a new protocol version :S ... > > So yeah, either one looks at the tor version or "you don't see it, not > overloaded" which is ofc a lie until the entire network migrates.
What if, once a day or 72 hours or something, a relay explicitly outputs "not overloaded" if they're not? > We expect our sbws (bandwidth scanner tool) to be the main customer > for this. I know at least one research group that would be very interested in these stats as well. :-) -- Ian Goldberg Canada Research Chair in Privacy Enhancing Technologies Professor, Cheriton School of Computer Science University of Waterloo _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev