Hi,
On 20 Jan 2020, at 17:43, Georg Koppen gk@torproject.org wrote:
nusenu:
Georg Koppen:
Yes, that's what I figured. So, it seems to me not all your proposed keys are equally important (e.g. your require the email one). Which of those (or maybe even which cluster of those) are/is important enough in your opinion to could be considered on topic for a potential tor proposal? (If we would go that route)
email (if a fully automated verification process is included)
Okay, that sounds like a promising start.
The only negative point of removing the ContactInfo field altogether is loosing information that people put into it.
Well, it does not necessarily mean losing information as the field would not just go away but be replaced by other, more narrowed down ones.
which seems to imply a configuration change and not all operators will change their configuration
That might be true but we'd have some clear process ahead to phase the old field out and transition to the newer ones, and transparent ways to enforce the new model after some time.
I feel that's a big plus to an optional spec that kind of exists in parallel to the status quo and might play somehow a role in determining whether a relay might get bumped out of the network or not etc.
If we want to recommend that operators provide an email address to stay in the consensus, we should make it easy for operators to provide an email. If we have a preferred format, we should automatically provide the email in that format.
Here's a rough sketch of a spec that could work: * add a ContactEmail field to the torrc and descriptors. The field must be encoded as UTF-8. (See proposal 285 [0].) * do some minimal validation on the email field, that makes sure it looks like an email address. (Or don't, so operators can obfuscate their addresses from spammers.)
And then there's a few different transition options, some of which overlap: 0. Do nothing. 1. Combine ContactEmail and ContactInfo in the descriptor's ContactInfo field, in the format that the ContactInfo spec recommends. If the email is already a substring of ContactInfo: 1.1. Do nothing. 1.2. Make sure the ContactInfo email is in the format that the ContactInfo spec recommends. 1.3. Remove the email (and the ContactInfo spec email field name) from the ContactInfo field in the descriptor, and just put it in the ContactEmail field. We could wait a few releases to make this breaking change. 2. Warn if the ContactEmail field isn't set on a relay. 3. Reject the configuration if the ContactEmail field isn't set on a relay, after a few releases. 4. Rename ContactInfo to OtherContactInfo, but allow ContactInfo as an alias for a few releases. 5. Deprecate the ContactInfo field in descriptors, and replace it with the email and other contact info fields, after distributing them in parallel for a few releases.
Here's my opinion:
I'd prefer no validation, combining the fields, and ensuring the email is in the ContactInfo spec format. I think we should give a config warning if the email is missing.
Eventually, we should probably stop duplicating email in the ContactInfo and ContactEmail fields. (Although compression helps mitigate the impact of this kind of duplication.)
I don't think we should rename ContactInfo. It is one way to force operators to eventually modify their torrc. But if we want to force a config change, let's just require that ContactEmail is set.
I don't think renaming or deprecating ContactInfo in the descriptor is useful. (Renaming a field breaks a bunch of tools for no good reason. And people clearly like having an unstructured or extensible field.)
But that's all just my opinion. I've run relays, and made changes to tor, but I don't work with this data every day. (Occasionally, I use it as part of selecting fallback directory mirrors.)
Any proposed Tor changes should be guided by people who deal with this data all the time: the network health, bad relays, and metrics teams. (And the network team, to help with the design and implementation in Tor.)
T
[0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt
T