Hi everyone,

Colleagues

Someone has kindly referred me to the conversation you had last November on this same paragraph 6.2. It's not surprising that there is some reluctance to discuss it again. BUT this is a different discussion. Last time you focussed on defining what type of network needs to be separately registered in the RIPE Database. I want to discuss the next step from that. Once you have decided a type of network needs to be separately registered then what information about that network needs to be entered into the RIPE Database?

Denis, I believe that the first e-mail sent by you was inviting the community to start a conversation. Furthermore, I believe that NOW is the right time to have this discussion and clarify what is required by policy (and maybe look at updating those policies as well) and put it in writing in a new privacy policy.

While GDPR is already in effect, the RIPE Database contains millions of contact details of private persons. Some ISPs currently use the RIPE DB as their customer database and register every single assignment they make to organisations or people. I doubt any of the people used by the ISPs as admin-c or tech-c in assignments actually know that their private data is made public in the RIPE DB. Lastly, and this can be fixed easily if we all ask for it, the RIPE NCC is creating every month hundreds of objects that contain personal details with the registration of new LIRs. The current state requires an update of policies and processes and can not continue like this much longer.

I doubt that everyone that has a person object (containing personal details - phone, e-mail, address, etc) in the RIPE Database even knows about their personal data being public. I also doubt that every person that registers a new LIR knows that their personal details will be published in the RIPE Database and made publicly available. There are several million person objects in the RIPE Database that (I believe) should have been deleted once GDPR kicked-in _or_ all of those persons should have been asked to confirm that they accept to have their private information made public in the RIPE Database.

To quote Peter Hessler "I am *not* happy for that data to be published widely on the internet, so I have censored them on purpose" - this is one way to hide personal details, many other companies/people have chosen to censor or provide less than accurate details.

Jan Ingvoldstad wants to see a better usable abuse contact information. This is one of the details that we are asking for. We are trying to make a list of contact information you all would like to see registered in the RIPE Database for resource holders and the questions in Denis' initial e-mail were supposed to start and steer the conversation into finding exactly those details - to then clarify and define where that information should be stored (role object, org object, maintainer, etc)

Michiel Klaver had an interesting idea "Maybe make more use of the 'role'-objects? Within organisations people come and go, while their departments responsible for network operations and abuse keep rolling. Listing a department as role and using a shared e-mail address would reduce the ever increase of new person-objects in the database." and I believe that the use of the role objects should trump the use of the person object.

I personally believe that we should remove the person object from the RIPE Database and use roles/organizations/maintainers/etc instead.

I will come straight to the point, which should be controversial enough to start a discussion :) MY interpretation of the wording in 6.2 is that the policy, as written, requires an ORGANISATION object to be created for these End Users if you register their network in the RIPE Database.

Let me explain my reasoning for this interpretation. The policy refers to the End User as either an individual or an organisation. In other words the End User is the '(legal) entity' that operates the network. Just as the LIR is the (legal) entity that holds the allocation resource. So when the policy requires the contact details of the End User, it is requiring the contact details of this operating entity. That is not the "xxx-c" attributes in the INETNUM object, it is an ORGANISATION object details.

I believe that first we need to decide what kind of data must be published in the RIPE Database and then decide in which objects to store that data - be it an organisation object, admin-c/tech-c/abuse-c, or a role object.

Once this is clear, we can amend current policies or propose a privacy policy and reference it in the other policies.

This takes us back to the long running discussion we had with "abuse-c:" where many members refused to create separate ORGANISATION objects for End Users just to add an "abuse-c:" for them. But as it is currently written, this is exactly what this policy requires. Perhaps the wording of this paragraph 6.2 doesn't reflect the original intent. So what we must now do is look again at this situation and answer 3 basic questions about these End Users:

1/ What information do we need/want to store about the End User?

I'll bite and provide my answers:

- we should not store names of people - people come and go and usually there is one person within a department that creates the objects & requests the resources and then those objects are inherited for many years. I believe that roles/department names should be used. RIPE NCC has always recommended the use of role objects for admin-c/tech-c/abuse-c. I am not sure when the RIPE NCC changed their procedures and forms to include registration and publication of personal data with the registration of every new LIR but I believe they should revert and create role objects instead.

- I think we should have an e-mail address and a phone number - none of these should be personal details but the org's contact details instead.

- physical address will come with a lot of questions: should this be the legal or the mailing address of the org, of their tech dept, of their outsourced tech dept in an other country, of their lawyer/legal dept, etc...

- fax - who is still using fax, will you even think you will need a fax sent to a holder of internet resources?

- what else is there? social media contacts? maybe links to forms? how complicated do we want this to be?

2/ What is the reason for storing this information?

great question. The only reasons I can find are:

- someone is breaking my network (hijacks, ddos, peering issues, etc) and I want to be able to swiftly contact them and ask them to stop

- someone is sending abuse to my network/customers/contacts and I want them to stop

- an LEA wants to be able to track the user of a resource swiftly and, when they need to issue a subpoena, they need to know the country where it should be sent and the right address

- the RIPE NCC already knows who is authorized to discuss confidential information, the name should not be public though unless the user really wants to and opts-in for his personal data to be in the RIPE DB.

There may be other reasons as well, we'll have to wait for other people to provide their feedback before we can collect it all and do something with it (make a policy proposal).

3/ Who needs this information?

If we can answer these basic questions then perhaps the policy needs to be updated.

cheers

denis

co-chair DB-WG

cheers,

elvis

On Monday, 15 April 2019, 16:18:33 CEST, ripedenis--- via address-policy-wg <address-policy-wg@ripe.net> wrote:

6.2 Network Infrastructure and End User Networks

When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.