[db-wg] 2022-01 New Policy Proposal (Personal Data in the RIPE Database)
- Previous message (by thread): [db-wg] 2022-01 New Policy Proposal (Personal Data in the RIPE Database)
- Next message (by thread): [db-wg] 2022-01 New Policy Proposal (Personal Data in the RIPE Database)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Cynthia Revström
me at cynthia.re
Wed May 25 12:17:24 CEST 2022
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 <db-wg at ripe.net> 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 <ripedenis at gmail.com> 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 <db-wg at ripe.net> 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 > > > <db-wg at ripe.net> 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 > > > > db-wg at ripe.net 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
- Previous message (by thread): [db-wg] 2022-01 New Policy Proposal (Personal Data in the RIPE Database)
- Next message (by thread): [db-wg] 2022-01 New Policy Proposal (Personal Data in the RIPE Database)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]