Greetings, Just a small note about "the law of a given country from where the LIR is from": In case someone didn't notice, this is really any country/economy in the world -- i.e. it is *not* restricted to the NCC's Service Region. Best Regards, Carlos Friaças On Thu, 21 Feb 2019, lir@unitelmedia.pl wrote:

Hello

You ask when they will start to comply with the law or rather adapt it to the requirements GDPR

I will add a question when will they start treating all LIRs the same?

The second question is when they start to respect the law of a given country from where the LIR is from ?

Promises of RIPE employees that they will improve procedures etc. are worth as much as rubbish thrown into the waste bin

So much on the subject I can add more but does it make any sense at all?

 

--

Grzegorz Dacka

 

 

From: members-discuss <members-discuss-bounces@ripe.net> On Behalf Of Elvis Daniel Velea Sent: Thursday, February 21, 2019 1:33 AM To: members-discuss@ripe.net Subject: [members-discuss] is the RIPE NCC GDPR compliant ?

 

Hi everyone,

this e-mail is addressed to the RIPE NCC, but because they have continuously ignored the issues raised at the RIPE Meeting in Amsterdam, I am going to formally ask them to fix these things which, I believe, are not GDPR compliant.

1. Ticketing system

- when someone wants to open a ticket with the RIPE NCC, the only way to do that is by sending an e-mail. It would be stupid to ask users to send e-mail without attachments (in order to open the ticket) and then go to the LIR Portal and upload documents to that ticket but it seems the RIPE NCC is asking exactly that from the members.

- when someone sends an e-mail to the RIPE NCC and includes documents (RIPE NCC often requests company registration documents and - sometimes - copies of passports/IDs) the links to those documents hosted on zendesk are returned to the sender and (sometimes) all the LIR contacts. If that e-mail is forwarded to anyone, it includes the zendesk links and therefore anyone that receives the RIPE NCC e-mail or a forward of that e-mail will receive links to company registration documents and IDs of people.

I doubt this is GDPR compliant and I would like a response from the RIPE NCC on why they have not fixed this issue even if it was reported 4 months ago.

Several ways to fix this:

- e-mails sent by zendesk should not include any link

- allow users to create tickets and communicate to the RIPE NCC via the LIR Portal and stop e-mail communication with members

2. RIPE DB

The RIPE NCC Customer Services Department forcefully (*) creates person objects in the RIPE Database _MAINTAINED BY THE MAINTAINER OF THE LIR!!!_ for the people that sign a contract with the RIPE NCC. It also forces companies that use role objects associated with their resources to actually have a person object referenced in the role object (so no circular reference or a reference to an other role object). Why is the RIPE NCC using the LIR's maintainer to create users without even requesting the LIR's acceptance? What else is the RIPE NCC creating with the LIR's maintainer?

I was under the impression that creating and publishing thousands of person objects in the RIPE Database may not be GDPR compliant. Actually, there was a discussion in Amsterdam about this and the general understanding is that companies that do this will be contacted by the RIPE NCC to stop doing it and clean up their data. Well, who will listen to an organization that does exactly what they should not be doing?

Why would you need to use a person object in the RIPE DB if a role object is an option?

Oh, to make things worse, every time someone registers an additional LIR, the RIPE NCC keeps creating duplicate objects instead of re-using the ones already created *by them*.

 

Dear RIPE NCC, when will you update your procedures to be GDPR compliant?

 

(*) We have created the following objects in the RIPE Database for <LIR>'s public profile:

[...]

ORGANISATION: https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=<ORG>&type=organisation MNTNER: https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=<MNT>&type=mntner ROLE: https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=<ROLE>&type=role

ADMIN-C: https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=<PERSON>&type=person TECH-C: https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=<PERSON>&type=person

Kind regards,

Elvis

--

Elvis Daniel Velea

V4Escrow LLC

Chief Executive Officer

E-mail: elvis@v4escrow.net

Mobile: +1 (702) 970 0921

Hello I did not express myself very clearly on this subject, but one of the problems is that if the law is in force in Poland and there are government services to verify the correctness of registration data, companies should check there in government services and not in which databases that are not up to date and not true, accusing later that I am sending documents that are not true. The next thing is to describe the names of companies. Unfortunately, RIPE does not have the right to change the name of the company and it does it differently depending on who reads and writes to him. Give more examples? -- Grzegorz Dacka From: members-discuss <members-discuss-bounces@ripe.net> On Behalf Of Franco Tauceri Sent: Thursday, February 21, 2019 1:13 PM To: members-discuss@ripe.net Subject: Re: [members-discuss] is the RIPE NCC GDPR compliant ? On 2019-02-21 09:02, lir@unitelmedia.pl <mailto:lir@unitelmedia.pl> wrote:

The second question is when they start to respect the law of a given country from where the LIR is from ?

Never. In the agreement you undersigned with RIPE it's clearly specified:

Article 11 – Governing Law 11.1 All agreements between the RIPE NCC and the Member shall be exclusively governed by the laws of the Netherlands.

So, it's YOU to be required to respect NL law. If NL law is in contrast with the law of your own country, it's an issue of yours, not of RIPE. Regards -- <https://domainregister.international/templates/dr/assets/images/dr-logo.svg> Franco Tauceri DomainRegister m: 39.3483064202 w: <https://DomainRegister.international> https://DomainRegister.international e: <mailto:franco.tauceri@domainregister.it> franco.tauceri@domainregister.it

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) On 2/21/19 08:53, Felipe Victolla Silveira wrote:

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.

Manual removal of the attachments from the ticketing system is prone to operator failure and as we are all human (and humans make mistakes) I believe this is the worse implementation. I hope you can make a better effort to have this automated before the next RIPE Meeting and report to us before or at RIPE 78. You were doing this manual removal even before RIPE 77, so what have you worked on in the past 4 months?

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

Hi Elvis, As I mentioned previously, we have been working on the issues you mention. You note that you have seen no progress on the ticketing issues. I can let you know that we have investigated all the options you mention (and more). Unfortunately, all options have some negative impacts and cause complexities for both the RIPE NCC and people who want to contact us. Granular-level reporting on our progress is not always possible or useful, especially as much of this work involves assessment of all options before a decision can be made. Reporting to our members while work is ongoing can be problematic, as it can create false expectations or spark discussion on outcomes that might not take place. We have heard all of your comments on our ticketing system and you can be sure we will factor them into our work. The Executive Board, which follows this list closely, is also made aware of our progress on a regular basis. We will also present our operational update at RIPE 78, and we will be sure to include further details then. Regarding the creation of objects in the RIPE Database, it’s important to be clear that here we are providing assistance for new RIPE NCC members. Objects are created by automated tooling, on behalf of the members, with the information they provide. Our tooling does not use the LIR's maintainer for authorising the creation or modification of objects. We are confident that we provide them with clear information on how the data they enter will be used and how they may update or delete it. In 2008, the Data Protection Task Force decided that there was a requirement to have personal data in the database. The RIPE Database Working Group has suggested that it is time to revisit this analysis and we agree with this assessment. However, it would not be appropriate for the RIPE NCC to unilaterally determine whether PERSON objects are needed. We will therefore follow the community’s lead. The discussions in the Database Working Group and elsewhere will ultimately inform all the decisions we take regarding personal data in the RIPE Database. And with multiple LIRs, it was not at all clear for a long time that the ability to create multiple LIRs would exist indefinitely. Indeed, the Executive Board prevented this via a resolution for a period until it became obvious that this led to people establishing new legal entities. The RIPE Database was set up to manage entries on an LIR basis, and it is not clear that changing this would be beneficial for RIPE Database users. Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC

On Thu, 21 Feb 2019 at 17:57, Felipe Victolla Silveira < ripencc-management@ripe.net> wrote:

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.

Thanks for the reminder. I just posted a message to the Database Working-group list to follow up on this discussion. -- Sincerely, Hans Petter Holen - hph@oslo.net - +47 45066054