[db-wg] 2022-01 Resource holders identity
- Previous message (by thread): [db-wg] 2022-01 Resource holders identity
- Next message (by thread): [db-wg] 2022-01 Resource holders identity
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at massar.ch
Tue May 31 16:20:43 CEST 2022
> On 31 May 2022, at 15:31, Ángel González Berdasco via db-wg <db-wg at ripe.net> wrote: > > 30-05-2022 a las 13:17 +0200, denis walker writes: >> If no one is able to present the public interest case for publishing >> the name and address of natural persons holding resources then the >> privacy case takes priority. If we cannot justify publishing this >> personal information based on the purposes, then the GDPR says very >> clearly that we must not publish it. All personal details of natural >> persons holding resources will have to be removed from the database >> or hidden from public view. This will also apply to assignments as >> well. >> There are many assignments with name and full address details of >> natural persons in the "descr:" attributes. We will have to remove >> the "descr:" attributes where the assignee is a natural person or >> hide them from public view. > > Please note that GDPR has the concept of processing based on consent. > It might not be necessary to remove them. And some of those affected, > may want them to stay published. > > I agree, however, that *not* publishing the home address of those that > hold a resource as a natural person is probably a good idea. Consent is the key bit indeed. But people can also chose to not use the RIPE DB. Personally, I don't mind having my name + email address in there, whois is for my purposes primarily a assignment DB ("is it an eyeball, is it a VPS network, it is a bunch of evil VPNs") but most importantly a "who is" database and thus contact: who to contact for a given resource, when one sees bad things coming out of it, when they have MTU issues, etc etc etc. As such, I personally would love to see the options: A) Publish name + email B) Publish name + email + phone C) Publish name + email + phone + address ('all') Personally B would be my option, the internet does not need to know where I physically am, but mail forwarding exists for that, making it an option though makes it clear one does not want to share that data and that it is just a forwarding place. But the problem is that some (not me) people want is: D) Hide all details Which would make whois for a person (they cannot have roles, otherwise they are not people) look like: person: Anonymous Person 172784394902 remarks: RIPE anonymized person -- https://www.ripe.net/contact/hiddenperson remarks: Responsible LIR: xx.lirhandle -- <handle>-RIPE -- https://www.website.com # autopopulated from LIR email: person-172784394902 at anon.ripe.net # forwarded mail nic-hdl: PERSON-172784394902-RIPE mnt-by: RIPE-NCC-ANON-MNT # Can't have own maintainer then either created: 2002-03-19T12:20:34Z last-modified: 2021-05-12T15:05:51Z source: RIPE # Filtered Thus email forwarding to not expose that data but still allowing contact and still allowing statistics/associations to be made based on the handle, but not private details to be released. (note that people can still drop all mail in /dev/null and chose to remain ignorant independent if the address is valid or goes anywhere at all; bad folks do not fix things) But I think it is a really bad idea; people who don't want to be named on the Internet already have options by hiding at a cloud provider or a VPS where they can borrow address space, they do not need to have their name in the RIPE DB. Note that such a policy would cause address space for the rest of the lifetime of IPv6 to be handled that way too; then just do not get your own prefix in the database. The above A/B/C ... yeah kinda makes sense; but option D, big nope from me. Greets, Jeroen
- Previous message (by thread): [db-wg] 2022-01 Resource holders identity
- Next message (by thread): [db-wg] 2022-01 Resource holders identity
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]