This came up quite a bit at the dbtf, where several of us came into the
discussion with fingers on the throttle of their chain saws.
By the end of the TF discussions, there was a pretty sober realisation
that it was not going to be trivial to get from where we are now, to
where we might want to be at some point in the future. There were a
bunch of things that were clear, though:
- many of the problems we see with person objects will recur with role
objects. Someone commented about this at the mic at the RIPE meeting
last week, and we cannot look away from this reality.
- setting a long term strategic object is fine, but it needs to be
realistic, and part of that assessment needs to include a migration path
from here to there. If the migration path is too steep or too
extensive, then the migration will fail.
- it would be important not throw the baby out with the bath water
I.e. gut feeling => probably better to pick away incrementally at this
issue rather than attempting to do a wholesale data reorientation /
translation project which would likely leave the db in worse shape than
before.
As Daniel said at one point, if this were an easy problem to solve,
someone would have already tackled it.
Nick
Cynthia Revström via db-wg wrote on 25/05/2022 11:17:
Hi denis,
I agree with your summary for the most part although I think that
if/how verification is done for contact details is slightly outside
the scope of the summary of what a contact is.
For what it's worth I do think it is probably a good idea to do
verification for e-mail addresses, maybe not recurring like for abuse
contacts but at least when the email address is set/changed.
Contacts listed for any other reasons should be removed.
With regards to this I do think that there might be legitimate use
cases that I just can't think of currently or that currently don't
exist but may exist in the future.
-Cynthia
On Tue, May 24, 2022 at 5:02 PM denis walker via db-wg <[email protected]> wrote:
Colleagues
I received quite a lot of feedback at RIPE 84 on this policy proposal.
This was mainly on two aspects, resource holders name and address and
contacts. I will start with a summary of the views on contacts as this
is the easier one to deal with.
Contacts are listed in the RIPE Database to resolve issues. Currently
these are technical, administrative, abuse, routing and DNS issues.
They can also be listed for external services like RIPE Atlas and
IRTs. Other issues or services may be added in the future. Contacts
should only exist in the database if they are relevant to one of these
defined reasons. Contacts listed for any other reasons should be
removed.
A contact needs to be contactable. The whole RIPE philosophy is built
around email. So every listed contact must have a mandatory and
working email address. This should be verified on entry into the
database.
Any other means of contact should be optional. These other means may
have dedicated attributes like phone and fax. Or they can be added via
remarks to include, for example, a URL for a web form, irc, a facebook
group, or any other social media. Any of these other means may have
dedicated attributes added if there is sufficient interest. These
other means should also be verified on entry into the database, where
technically possible.
Contacts are for resolving immediate issues. They are not for
receiving legal notices or arranging site visits. An address is
therefore not needed and should be deprecated from any form of
contact.
Identifiable individuals are not needed for the defined purposes of
contacts. All contacts should therefore be defined as business roles
and only contain non personal data.
Does this sound like a reasonable summary of contact details?
cheers
denis
proposal author
On Tue, 17 May 2022 at 11:03, denis walker <[email protected]> wrote:
Hi Cynthia and Peter
You both raise some interesting points and I will address them all in
one email. Let's start with 'why' do we publish the name and address
of resource holders. The RIPE Database is one of a set of 5 databases
that collectively document the registration of all global internet
resources. This is to offer to the public an open source of the 'who'
is using internet resources. Only by offering this information openly
can we have accountability at all levels of society. If this
information is closed with restricted access then accountability can
only be judged and enforced by lawful authorities.
So let's look in more detail at the consequences of open vs closed
data. This only applies to the name and address details of resource
holders who are natural persons as well as end users operating public
networks with assignments. No other personal data should even be
considered in this database.
In an open system the names and addresses of all internet resource
holders and public network operators are published. In an ideal world
all this data will be verified and accurate. This makes it easy for
anyone who is following up on criminal activity or abuse on the
internet to look up who is using a particular (block of) addresses.
This is not only LEAs. Private organisations and individuals can also
follow up abuse and take civil actions against the abusers.
In a closed system we don't publish names or addresses of natural
people. The information will be held by the RIPE NCC or a member or a
sub allocation holder, or ... This gives maximum privacy protection
for natural persons, but causes problems for anyone trying to address
criminal activities or abuse on the internet. This arrangement can be
further manipulated by the bad actors to hide their tracks. Suppose a
natural person in country A becomes a member. Their details are not
published. They sub-allocate to a natural person in country B who
assigns to a natural person in country C. None of their details are
published. If this assignee is an abuser, an LEA, or other
organisation, has to get a court order in the Netherlands to get the
details of the resource holder in country A from the RIPE NCC. Then
they need a court order in country A to get the details of the sub
allocation holder. Then they need a court order in country B to get
the details of the assignee. If we go down this closed system route we
may have to look at who has a right to this information (which is
currently public) and how....but that is outside the scope of this
policy proposal.
Another option, where a resource holder is a natural person, is to
'require' them to have an official, legal address such as an
accountant or lawyer office, with their consent to publish that (non
personal) address.
Having a simple rule like 'we don't publish names or addresses of
natural persons' is easier to apply and less error prone. But we are
turning the RIPE Database into more like a domain registry where lots
of details are hidden from public view. Does this affect the
usefulness of the RIPE Database as a public registry?
I think it is a good idea to extend the scope of this policy to
include anywhere that the RIPE NCC publishes personal details of
members. So it would include the web pages where members are listed.
cheers
denis
On Fri, 13 May 2022 at 00:56, Cynthia Revström via db-wg <[email protected]> wrote:
Hi,
I am generally in support of this policy, however I do wonder why
publish legal names of individuals in the cases of natural persons
holding resources?
Like why can't it just be some alias and the real name needs to be
requested from the RIPE NCC by court order or whatever would be
required for physical addresses under this proposal.
While my name is a bad example, there are plenty of names that are
extremely common, and if all that is published is the name and
country, is it really all that useful?
It is not like knowing that it is someone in the United States with
the name "Joe Smith" is particularly useful on its own to know who it
is.
But on the other hand in such cases it is not a big privacy problem I suppose.
However with a name like mine it is a privacy concern as my name is
not exactly common.
I would like to hear what the reason would be for requiring this to be
published if it is either kinda pointless information or still a big
privacy issue.
Also I have a kinda Sweden-specific question about the following part
(from 1.0 Organisations):
personal address for the organisation which is already in the public domain in
a national, public, business registry.
In Sweden there are multiple private organizations that publish home
addresses for almost everyone in the country by combining some quirks
of the freedom of the press act and government transparency.
Would this count according to that, and as such would you say it is
okay to publish the personal addresses for almost everyone in Sweden?
The government doesn't directly publish this information, people have
no right to demand to be excluded but it is still public.
The important thing here though imo is that these websites generally
are a lot harder to scrape than the RIPE Database.
Also what if it was an address that was kinda public but you had to
create an account and agree to not re-publish it elsewhere, would that
make it okay or not okay to publish?
Or what if that address is published somewhere, but not linked to that
person's name, maybe it is linked to some unrelated legal entity that
is on the same address, would that make it okay to publish?
I think it would be a lot easier to just say that personal addresses
should never be published.
Just because it is already somewhere on the internet doesn't mean that
the RIPE Database has to spread it further.
-Cynthia
On Tue, May 10, 2022 at 11:29 AM Angela Dall'Ara via db-wg
<[email protected]> wrote:
Dear colleagues,
A new RIPE Policy proposal, 2022-01, "Personal Data in the RIPE Database"
is now available for discussion.
The goal of this proposal is to allow the publication of verified Personal Data
in the RIPE Database only when they are justified by its purpose.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2022-01
As per the RIPE Policy Development Process (PDP), the purpose of this four week
Discussion Phase
is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the WG
Chairs, will decide how to proceed with the proposal.
The PDP document can be found at:
https://www.ripe.net/publications/docs/ripe-710
We encourage you to review this proposal and send your comments to
[email protected] before 8 June 2022.
Kind regards,
Angela Dall'Ara
Policy Officer
RIPE NCC
--
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
--
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
