Hi Sasha, I think you have partially understood it but also just the NCC's side. I think both myself and others have argued basically the same thing you are arguing here but in slightly different words. I have talked about how it makes no sense to not be able to publish a geofeed url for a prefix you can publish an admin-c and tech-c for (and other personal details). And how the NCC is not publishing the data in the geofeed, but simply publishing a URL. I think this is also why it has gone on for so long, myself and others find it extremely confusing or difficult to understand how this could possibly make any sense. -Cynthia On Thu, Feb 24, 2022 at 11:20 PM Sasha Romijn via db-wg <db-wg@ripe.net> wrote:
Hi all,
On 24 Feb 2022, at 16:48, Edward Shryane via db-wg wrote:
This is intentional and as currently implemented, we do not allow geofeed on any assignments that are reasonably assumed to be related to one individual user.
From the Legal analysis in November:
I am very puzzled by this entire thread.
We’re in this giant thread, picking apart statuses and prefix sizes, with the goal of reliably determining when an inet(6)num is considered “reasonably assumed to be related to one individual user”, because legal said you can’t have a geofeed attribute then. Which they have said because at that point, this would introduce additional personal data which creates GDPR issues. Right?
To start with, this works in one direction: if my ISP gives me, an individual person, a /56, and creates an inet6num for that, and adds a geofeed attribute, I can see the case that geofeed on that inet6num could be seen as personal data. But then, the actual issue is with the inet6num being created, rather than the geofeed attribute specifically. All the concerns about geofeed apply to all the other fields. If my ISP puts my name in the netname, we have exactly the same kind of problem. So the issue here would not be “does the database allow geofeed” but “which inet(6)nums are being created, do they contain personal data, and does that meet GDPR?”.
But it gets worse: by having a list of rules of where you can add geofeed, we haven’t stopped people from publishing personal data. If I publish a geofeed for my /32 ALLOCATED-BY-RIR, I could list every individual customer with a /48 in there with their location. It can be as granular and personal as I want. So we haven’t actually prevented any publication of personal data.
In short: this conversation sounds like we think the geofeed attribute says something about the location of an inet(6)num. But actually, it may say something about each individual IP address in that inet(6)num.
Now, you could argue that that is my problem: the geofeed is on my server, this is about my customers, I’m responsible. The RIPE db merely contains a URL. But if that is the position, why can’t I put a URL, where I am responsible for the contents, in my ASSIGNED PI /48? Either the RIPE db is responsible for the personal data in that URL, and by extension we consider that as publishing personal data in the RIPE db, or it is not.
Sasha
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg