[tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02

[teor]

Hi,

> On 20 Jan 2020, at 17:43, Georg Koppen <gk at 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

-- 
teor
----------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200120/ec45f537/attachment.html>