nusenu:
Hi,
I made some updates to the ContactInfo Information Sharing Specification draft.
Most notably I added a new field 'verifyurl' that should allow the automatic verification of the operatorurl claim.
Without it anyone could claim to be part of some operator without the possibility of automated verification.
You can get the current version on github:
https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/blob...
Thanks for writing that draft. I've been looking over earlier discussions of it on tor-dev[1] and tor-relays[2] to get more context for that write-up and I have some questions and suggestions.
It seems to me the specification tries to make use of the fact that the ContactInfo field is essentially unstructured text to put things into it, in a slightly structured manner, that could be helpful in a number of areas (bad relay detection, relay metrics, network growth...). I, like others, fear a potential function-creep here essentially wasting the time you put into this important work because nobody is adopting your suggestions (they are opt-in according to your writing). So, my suggestion would be to take a step back and think harder about whether all of those areas would really benefit from the work in your specification or whether we should try to get improvements elsewhere going instead (E.g. I like the idea mentioned by Iain to think about new fields for extrainfo documents[4] for some of this information).
As another suggestion that could help thinking about your spec: what about ahf's idea to deprecate ContactInfo and replace it with a more structured format instead? That could go along with the areas above which we *actually* think should be covered by the (original) ContactInfo field?
Please send me your comments before 2020-02-02. I'm planing to tag a v1.0 in February 2020.
After that I hope it sees some adoption by major operators so I can use your ContactInfo strings for automated verification and as input for malicious relay detection.
That's one part I don't understand. You advertise the specification as opt-in and relay operators are free to choose from any of the options[5] but your wording above seems to imply that not following it could make the probability higher that the relay will be marked as bad exit. So, there is supposed to happen a silent enforcement over time of an opt-in spec which is a weird thing to me. (Additionally, what does it mean in your spec that "The email field MUST be provided" given that the whole spec is opt-in?) Again as I said above: we should think about the different areas this spec covers, and if there is anything we want to enforce for $purpose we should think about the best way to do so (having the longer term costs associated with what we pick in mind, too) and then do it. However, we should avoid any ambiguity in that case and not get to a slow enforcement of things we originally propagated as merely opt-in.
Georg
[1] https://lists.torproject.org/pipermail/tor-dev/2017-October/012507.html ff. [2] https://lists.torproject.org/pipermail/tor-relays/2017-October/013274.html ff. [3] https://trac.torproject.org/projects/tor/ticket/24526#comment:3 [4] https://lists.torproject.org/pipermail/tor-relays/2017-October/013275.html [5] https://lists.torproject.org/pipermail/tor-dev/2017-October/012509.html