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