[db-wg] The DBTF needs your feedback!

> Note that the task force has already published an incomplete draft of
> the requirements, so you can see what we have in mind:
>
> https://www.ripe.net/resolveuid/ec75a6eb21684150bbcf6cd53917629c

I've read this with interest and also the discussion in this
thread.

I wish to make a comment in this context.

The above quoted document doesn't really discuss what tools should
be available to discourage undesireable actions on "the fringes" of
our environment, typically actions which don't enjoy the light of
day.  One aspect to discourage such actions is "transparency", and
that's hardly mentioned or discussed as a goal.

I would dislike for the usefullness of the RIPE DB to devolve to
the same state of affairs the domain registry business has done.
As a random example:

   Domain Name: WHOISTHAT.COM
   Registry Domain ID: 85429666_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.enom.com
   Registrar URL: http://www.enom.com
   Updated Date: 2020-03-31T08:22:02Z
   Creation Date: 2002-04-09T21:59:54Z
   Registry Expiry Date: 2021-04-09T21:59:54Z
   Registrar: eNom, LLC
   Registrar IANA ID: 48
   Registrar Abuse Contact Email:
   Registrar Abuse Contact Phone:
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Name Server: NS1.DSREDIRECTION.COM
   Name Server: NS2.DSREDIRECTION.COM
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2021-02-04T13:22:21Z <<<

There's not exactly many hooks to grab onto in this information
to know who or which organization actually stands behind this
domain.

There also isn't a lot of discussion about what tools are already
available if one wants to "hide in plain sight" in the RIPE DB.
E.g. a "role" only has the following mandatory elements:

role:           [mandatory]  [single]     [lookup key]
address:        [mandatory]  [multiple]   [ ]
e-mail:         [mandatory]  [multiple]   [lookup key]
nic-hdl:        [mandatory]  [single]     [primary/lookup key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
created:        [generated]  [single]     [ ]
last-modified:  [generated]  [single]     [ ]
source:         [mandatory]  [single]     [ ]

...and... I guess the e-mail address isn't validated as being a
working e-mail address, or leading to "the right place" either; and
phone and fax# are both optional, and quite a bit of the other
information isn't really verified either, so could very well be
falsified.

And ... for an inetnum, all the mandatory fields are:

inetnum:        [mandatory]  [single]     [primary/lookup key]
netname:        [mandatory]  [single]     [lookup key]
country:        [mandatory]  [multiple]   [ ]
admin-c:        [mandatory]  [multiple]   [inverse key]
tech-c:         [mandatory]  [multiple]   [inverse key]
status:         [mandatory]  [single]     [ ]
mnt-by:         [mandatory]  [multiple]   [inverse key]
created:        [generated]  [single]     [ ]
last-modified:  [generated]  [single]     [ ]
source:         [mandatory]  [single]     [ ]

If the admin-c and tech-c can all be populated with a reference
to a role with more-or-less anonymized contents, we're really not
very far from the awful domain whois listing above.

In other words, a bad-faith actor could already very well hide in
plain sight, using the RIPE DB as a "privacy tax haven".

I miss a discussion of what impact this push for ever more
privacy has on transparency, and whether it is relevant to
discuss the weighing of transparency on the one hand and privacy
on the other.

Regards,

- Håvard