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 <[email protected]> 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 -- 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
