Colleagues
Up to now we have focused mostly on member's personal data. But this
isn't only about members. The database contains lots of personal data
for end users as well. The INET(6)NUM objects have a "descr:"
attribute. This has been used extensively for (personal) data about
end users, mostly name and address, but maybe also phone numbers.
There may well be more of these who are natural persons than members.
There are 4.2m INETNUM objects in the database. So the scale of the
problem may be far higher here.
This is also a more complicated problem. The data is entered by
resource holders and possibly multiple levels of sub-allocation
holders. The issue of informed consent is hard to judge. Consent may
be in the small print of a contract and it may not be clear to the
data subject just what they are consenting to. The RIPE Database may
contain the home address of many end users without them knowing what
this database is or what the consequences are of publishing their
personal data in it. This data is also unstructured, unverified,
undefined free text.
As with member's data there are pros and cons regarding the usefulness
of this data. Also the defined purposes of the database cover adding
the name and phone number of an end user as part of the public
registry, but again not their home address. With the data being
undefined, it is not clear what any address relates to. We don't know
what address the resource holder asked for or what address the end
user supplied. The address, therefore, has no meaning to anyone
reading this data.
So the question we need to discuss is what do we do with this data in
the "descr:" attributes? Perhaps I can start the discussion with a
suggestion.
First of all we should never overload free text attributes with
structured data. So if we want to add a name and address to resource
objects we should include user name and address attributes. If we are
going to add a new address field we should break it down into a
structured set of address attributes, as all addresses should have
been from the start. Maybe a phone and/or email attribute is also
needed, keeping in mind most end users don't usually have an
ORGANISATION object. Any new attributes can all be optional, as it is
by choice that resource holders currently add any such data into the
"descr:" attributes.
The same rules would apply to this data as we have discussed with the
members' data. Phone and email must be business data and not personal
and they will be verified. (I will explain more about verification in
response to Leo's email.) Name may be personal if the end user is a
natural person. In that case any optional address added must not be
more specific than country and region.
Another possible solution could be to optionally create an
ORGANISATION object for end users. Either way, this data should not be
in the "descr:" attribute.
Most of this can be discussed later with the implementation details.
What is really important as far as this policy proposal is concerned
is the recognition that the same principles of processing personal
data will be applied to end users as it is to members, regardless of
what objects the data is stored in.
cheers
denis
Proposal author
