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