Hi Felipe,

thank you for your swift answer. Please see some comments and more questions inline.

(to everyone reading my e-mail, apologies for this lengthy e-mail and for repeating myself trying to make a point)

Dear Elvis,

Thanks for your email. We haven't forgotten the issues that were raised at RIPE 77 and are working on them (some since before that meeting).

In short, these are not trivial issues. They will take some time to resolve technically and some will depend on community input. But to address your points directly:

1. Ticketing
Email is not the only way to open a ticket with the RIPE NCC. You can also use the RIPE NCC Contact Form or one of the request forms in the LIR Portal. This allows for the secure and confidential upload of documentation and avoids the issue you mention regarding links to documents appearing in email responses from the RIPE NCC. When people email us, we actively direct them to upload documents via the LIR Portal.

We are working to address this, although there are limitations to what is possible with our ticketing system. A simple option would indeed be to no longer accept attachments via email, although we would need to balance this against the ability of people to interact effectively with the RIPE NCC.

There are lots of options here. The main concern is that these documents are held on the servers operated by a third party and links to these personal documents are provided when a ticket is created. I have not seen any progress reported in the past 4 months, please provide some details about what you have already done in the past 4 months to tackle this issue. Are you or zendesk GDPR compliant when providing public access to this data without the agreement of the owner of that personal data?

So, even if we all agree that the ticketing system has limitations and it is wise not to restrict the ability of people to interact effectively with the RIPE NCC, the fact that the documents are uploaded to a third party's servers (zendesk) and made available for free to anyone that knows (or tries to guess) the link is - to me - extremely concerning. Why on earth have you changed a very old ticketing system with one that is already flawed and limited, I do not understand.

How much money has the RIPE NCC spent for the change from xrtt to zendesk? How much is the RIPE NCC paying zendesk yearly?

This issue has been raised by other members as well, even before the RIPE 77 meeting. There has been no visible progress, so - as you say you are working on this - please provide us with some clarification on what you have done already, what needs to be done further and how long this work will take. I am asking these details because I believe you have been ignoring our requests in the past few months and I am trying to assess whether the NCC is even listening to its members these days.

I can come up with a few suggestions, but it is up to the RIPE NCC to decide on the implementation.

- One of the suggestions would be to stop processing requests for changes that come via e-mail. That is not desirable and I think this approach should only be taken if the ticketing system can be fully incorporated in the LIR Portal. This is the most extreme solution I can suggest - migrate the ticketing system in the LIR Portal and request members to use only the portal to communicate with the RIPE NCC.

- another suggestion would be to have zendesk not return any links to the attachments. So, once someone sends an e-mail that includes an attachment, strip the link to the attachment from the reply zendesk sends back.

- another suggestion would be to keep the links in the reply received from zendesk but make them available only if the LIR logins with their SSO.

- another suggestion would be to restrict access to https://ripencc.zendesk.com/attachments/* from outside the RIPE NCC internal network, thus restricting access to those links to anyone else but the RIPE NCC.

There are probably many other fixes available. The only thing that matters here is that the RIPE NCC does everything possible to restrict access to personal documents by zendesk and anyone that has the link generated by zendesk - and quickly. It has been 4-6 months since this (to me, trivial) issue was reported and there is ZERO visible progress.

In the meantime, as we investigate different options, our staff are removing attachments from the ticketing system manually in order to mitigate these issues.

2. RIPE Database object creation
We create PERSON objects for new LIRs to make things easier for them. Before they get started with the membership application form, we tell them how we intend to use the information they provide. We also make it clear that they should make sure they have permission to submit the personal data of third parties.

Why do you create person objects and not role objects? Is it not clear to the RIPE NCC that generating and publishing private data in the RIPE Database may not be not GDPR compliant? What will it take to convince you that this is not GDPR compliant?

Shouldn't you have updated your procedure when GDPR got adopted? Was there any analysis done by the RIPE NCC CS department on the compliance to the GDPR of their internal procedures?

You have been hiding this problem under the carpet by taking the stance that you are a data processor and not the data controller. YOU create the data and you should be LIABLE for it, I believe.

Has the RIPE NCC discussed with the Dutch DPA (https://autoriteitpersoonsgegevens.nl/en/contact-dutch-dpa/contact-us) to make sure it is compliant with GDPR? If yes, can you please share the results of that analysis?

I am not an expert on GDPR but I believe the RIPE NCC is not doing a good enough job to clearly inform members of the type of data it uses and for which purpose. Also, I don't think the LIRs are offered at this moment a method to provide a proper consent for the processing of the personal data. The RIPE NCC needs to receive the consent of the LIR before it publishes personal information in the RIPE DB on its behalf and this consent must be informed and unambiguous - this is currently not the case, I believe.

Since before GDPR became an issue, our systems have created person-maintainer object pairs - we are looking at the implications of changing this to require role-maintainer pairs. Most of our work regarding the database over the past several months has focused on implementation of NWI-5 (out-of-region objects) and abuse-c validation, which was requested by the community. In 2019, we hope to be able to dedicate more resources to furthering work on the areas you identify. However, we also have to consider the wishes of the community.

You make it sound like you have always done things this way and therefore there's nothing that needs to be changed. I do not remember when the NCC started creating person objects in the RIPE Database once a new member signs up but this procedure should have been evaluated closely when you made your legal analysis you mention below. You are GENERATING personal data and publishing it to the RIPE Database to then tell the LIR - you are maintaining it so you may not be GDPR compliant, not us. How long do you plan to continue doing things this way before you seriously evaluate your procedures?

As a side note, has the RIPE NCC attempted to contact the LIRs/maintainers that publish/maintain the rest of the personal data in the RIPE Database to tell them they may not be GDPR compliant? Or is the RIPE NCC just waiting for one of the LIRs to be sued for possible non-GDPR compliance before they react?

Our legal analysis of the RIPE Database and GDPR was based on input from RIPE community members. It essentially said that personal data is entered into the database for a specific purpose – to support coordination between network operators, which can be vital in the event of an outage or security incident.

While I agree that contact details for a company are needed and very useful, I also believe that a role object instead of a person object should have been used since the 25th of May 2018. Most members will have a department handling technical or abuse issues and not a specific person. Actually, even before I started working for the RIPE NCC, while attending an LIR Training more than 15 years ago, the RIPE NCC had identified issues with linking person objects to resources and was recommending LIRs to use role objects to identify the technical contacts (admin-c/tech-c) of a company.

In today's world it is very rare that a person will be stuck doing the same job for many years or decades. People leave companies, advance to other positions, etc. Data entered in the RIPE Database is usually entered once and forgotten. Stale data is, I believe, the norm and not the exception. Even the RIPE NCC had identified this issue 15-20 years ago and a solution should have been found by now. Moreover, if YOU create data in the RIPE DB, YOU should maintain it and be LIABLE if this data is not compliant with GDPR.

If someone (LEAs and the likes) wants to know the person behind the resource, they can request this data from the country registrar of that company (the LIR). They can also get a subpoena and request the RIPE NCC to provide the name of the person that has signed the contract on behalf of that LIR. If a network operator needs to know who is behind a resource and they are not happy with just the company details, they can either use the contact details from the role object to ask for these details or query the company registrar in the country that company was registered. If the company registrar does not provide that data, why should the RIPE NCC?

At RIPE 77, the question was raised in the Database Working Group whether PERSON objects are really required. If this is the case, then it affects our legal analysis. However, we can't decide this ourselves - we will need the community to make this determination. As we understand it, the community will be looking at this issue closer in 2019 - and we will be watching and supporting this process.

Even the RIPE Chair was surprised that all these person objects (over 1M objects) have slipped through the GDPR legal analysis. Now I realize that SOME of these objects are actually created by the RIPE NCC and liability is immediately transferred to the LIR because the RIPE NCC uses the LIR's maintainer and will then say that they do not maintain the data. The general agreement during the RIPE 77 DB-WG session was that all this data is probably not GDPR compliant. How long is the RIPE NCC going to ignore this issue (as creators of some of this data)? Dear Hans, can you step in or is this the Board's responsibility and liability?

Is there fine print in the SSA that states that data registered in the RIPE DB by the RIPE NCC in the name of the LIR becomes the LIR's responsibility? Is the LIR through the SSA agreeing that the NCC can create data that may not GDPR compliant and take liability for this data? If such a statement exists in the SSA, can you please point to the link/article?

Can a single LIR sue the RIPE NCC for registering GDPR non-compliant data in the RIPE DB on their behalf? I believe one of the board members (Remco) told me at some point that thousands of LIRs need to agree before the RIPE NCC can be sued in front of a Dutch court. If that is true, the RIPE NCC can do whatever they want and still not risk any liability because I doubt someone can get thousands of LIRs to agree to a trial. Maybe someone from the Board can join this conversation. Remco, care to share your (or the Board's) opinion?

ICANN has already been going through a legal struggle to keep this data public and in the whois. Their "Temporary Specifications" have stripped all the personal data meanwhile. When is the RIPE NCC going to do the same and attempt to be GDPR compliant?

https://www.icann.org/news/announcement-2018-05-25-en

Regarding your final point, our systems were never intended to cater to multiple LIRs and so the duplication you mention is a natural consequence of this. When thinking about changes to fix the issue, we need to consider the wisdom of spending resources to cater to this sub-set of members instead of improvements that would benefit the wider community and membership.

So, please explain to me who is liable for this data that you register in the RIPE DB. The LIR does not register the personal data in the RIPE Database, it is the RIPE NCC registering this data in the RIPE Database. Why on Earth are you using the LIR's maintainer to create data in the RIPE Database? If YOU create this data, YOU should maintain it. Why are you using MY maintainer to create data in the RIPE Database that may not be GDPR compliant?

What other data do you create in the RIPE Database by overriding a company's (LIR) maintainer? I do not want the RIPE NCC to use my maintainer to create data in the RIPE Database and I doubt I ever gave the NCC this permission but this may be mentioned in the fine print which I missed, and if so, please let me know the article in the SSA that allows the NCC to do exactly that.

Lastly, I think you are making too much of a big fuss about the multiple LIR issue. You have known about the possibility that people/companies can create multiple LIRs even before the runout in 2012. WHY is the RIPE NCC creating duplicate data when they could easily reuse for LIR[2-n] the data they have already registered for LIR1. How hard is it to include in the CS procedures another step where if a company registeres a 2nd or a nth LIR, CS will re-use the same data from LIR1?

To clarify, are you saying that you prefer to create duplicate data instead of changing a simple procedure and adding one extra step, just because you think this will spend resources of the NCC? I am baffled by your response to this issue and I hope you will evaluate all of the internal procedures and fix them.

Kind regards,

Elvis

-- 
Elvis Daniel Velea
V4Escrow LLC
Chief Executive Officer
E-mail: elvis@v4escrow.net
Mobile: +1 (702) 970 0921