[db-wg] 2022-01 Resource holders identity

Hi Tyrasuki


On Tue, 31 May 2022 at 07:24, Tyrasuki <me at tyrasuki.be> wrote:
>
> Hi Denis,
>
> I assume yes, but has it already been suggested to go for a
> middle-ground, and have resources possibly identified by for example, a
> nickname / username?

That could be quite complicated and not sure of the benefit.
Especially with assignments. How would we know the same nickname was
used each time for a specific person?

>
> As an example, I use Tyrasuki everywhere as my online nickname, and I
> hold 4 PI assignments and 2 ASNs.

But there is a PERSON and ORGANISATION object in the database with
your full name and address details. These are linked to several
INET(6)NUM and AUT-NUM objects. So your personal details are fully
exposed.

>
> This would still make it possible for people to know I operate the
> network, and I can then, on for example my personal site, list contact
> details if I'd find this necessary.

Contacts are not an issue. They can be fully documented without
personal data (check out the thread on this list about contact
details).

cheers
denis
proposal author

>
> Or even on PeeringDB for that matter. :)
>
> (I might have possibly glimpsed over this a bit too quick if this was
> already ruled out of the question)
>
> As for public interest, the only reason I could see it being relevant is
> to know who to address in mails.
>
> PS: I am writing this directly instead of to the mailing list, as I'm
> not sure if my points mentioned above make a lot of sense or not. (It's
> currently 7:00 in the morning and I've been up all night debugging
> hardware. :) )
>
> Kind regards,
> Tyrasuki
>
> https://tyrasuki.be
> F587 F089 1655 A5E0
>
> On 5/30/2022 1:17 PM, denis walker via db-wg wrote:
> > Colleagues
> >
> > We had a good discussion on contact details, I am hoping we can do the
> > same on resource holder identity. I know there is reluctance in the
> > community to get into a deep discussion on the purposes of the RIPE
> > Database. The Task Force sidestepped the issue as far as any public
> > discussion is concerned. It is a difficult subject. The use of the
> > database as a public registry is not in question. We do need an
> > updated understanding of what that means.
> >
> > 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.
> >
> > We need to have this discussion now and reach a new consensus, no
> > matter how difficult it is...otherwise privacy overrides all other
> > concerns, which may be the new consensus anyway.
> >
> > cheers
> > denis
> > proposal author
> >
> > On Thu, 26 May 2022 at 16:29, denis walker <ripedenis at gmail.com> wrote:
> >>
> >> Colleagues
> >>
> >> Now we move on to the more difficult issue of identifying resource
> >> holders. For any resource holder that is not a natural person I don't
> >> think there is a privacy issue. For natural persons we seem to have
> >> this conflict between privacy and public interest. The privacy issue
> >> is well understood. Publishing the name and address of a natural
> >> person in an open, public database can have severe consequences. But
> >> what is the public interest?
> >>
> >> To understand this question we have to dig deep into the purpose of
> >> the RIPE Database. Terms are thrown around with little consideration
> >> to what they actually mean. We all know the RIPE Database is a 'public
> >> registry', but what does that really mean? What is it a registry of,
> >> why does it need to register this, who needs to know what and why?
> >> After 30 years maybe we need to re-evaluate the fundamental purpose of
> >> this database.
> >>
> >> The database is a number, routing and reverse delegation registry. The
> >> routing and delegation elements generally don't include personal data,
> >> so we can put them to one side for the moment. What is the number
> >> registry? It 'documents' IP addresses (IPv4 and IPv6). It is arguable
> >> if ASNs are part of the number or routing registry. Although they are
> >> Internet resources, the "org:" attribute is optional so it is not
> >> possible to identify the resource holder of an ASN using the database.
> >> There are a number of reasons that have been given over the years for
> >> why this documentation is required. To ensure allocations and
> >> assignments are unique. To know what parts of allocations are 'in use'
> >> by end users. To identify who is responsible for a block of address
> >> space. To have a means of contacting network operators for several
> >> reasons.
> >>
> >> We have already discussed contacts, so the key issue here relating to
> >> both privacy and public interest is identifying who is responsible for
> >> a block of address space. Let's consider why this needs to be done and
> >> who needs to know. ORGANISATION and INET(6)NUM objects all reference
> >> contacts. So if there are any technical, administrative or abuse
> >> issues there are contacts who can handle these issues. We have already
> >> agreed that contacts must be contactable and they must only exist in
> >> the database if they are capable of addressing the related issues. So
> >> what is the reason for wanting or needing to be able to identify who
> >> is responsible for a block of address space and where to find them?
> >> Taking away all the issues that contacts can handle, are we down to
> >> purely legal matters? Is it for those cases involving criminal or
> >> abusive behaviour that someone wants to hold the responsible party
> >> accountable or liable? Are there research and investigatory reasons
> >> for identifying the holders of blocks? Do some people want to cross
> >> reference assignments held by individuals or organisations from
> >> multiple, different resource holders to monitor activities? If so, is
> >> it in the public interest and should it override privacy?
> >>
> >> Before we can decide on the priorities of privacy vs public interest,
> >> we need to understand what that public interest is. How does that
> >> public interest fit with the purpose of the database? We need to have
> >> this discussion now on the purpose of the database and the public
> >> interest, or not, in certain bits of data to decide if the identities
> >> of natural persons holding resources can, should, must be hidden from
> >> public view.
> >>
> >> cheers
> >> denis
> >> proposal author
> >
>