Hi Denis, I would like to acknowledge that all our legal framework documents, including the RIPE Database Terms and Conditions, are written by legal professionals. As to your other points, if a person object gets referenced in a resource object, it will be the Maintainer of the resource object who is responsible for ensuring the contact details are correct and accurate. This is because it is the Maintainer of the resource object that can make updates in that object. Similarly in your second example, it is the responsibility of the Maintainer who enters the data in the RIPE Database to ensure they have informed the relevant individual and keep their data correct and up-to-date. Having parts of this process delegated to different people does not change the fact that the relevant individual was informed about the processing of their personal data for the purposes of the RIPE Database and agreed to it. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC On Sun, 12 May 2024 at 02:25, denis walker <ripedenis@gmail.com> wrote:
Hi Maria
Oh dear!!! I wasn't going to respond to this. No one is interested in getting things right, so why should I bother? But I read it again and it is sooooo wrong, I couldn't just walk away. Let's go back to 2010. The RIPE Database Terms and Conditions is one of the most important corporate documents of the RIPE NCC concerning it's activity as an Internet registry. But this document was not written by legal experts. It was mostly written by me. I am an engineer, not a lawyer. What I wrote was approved by the Data Protection Task Force, not overflowing with legal experts. Then it was rubber stamped by the community, also not well known for expert legal opinion. As an engineer, I should never have been tasked with writing an important legal document. But the RIPE NCC was only just starting to bring in a legal expert. There was no one else so I volunteered to write it. I did my best, but I got it wrong. A lot of what I wrote about responsibility and liability, especially related to maintainers, is wrong. Responsibility and liability are key legal issues. An engineer's view is not the same as a lawyers. If you ever tried to enforce what the T&C says on these issues relating to maintainers, you would lose the argument. It is seriously flawed. The RIPE NCC now has a whole team of legal experts. But you have never reviewed the T&C document. All my mistakes are still there.
Let's now jump to 2018 when you wrote this labs article. It has built on what I wrote in the T&C. So the labs article is also fundamentally flawed. You also wrote that labs article 6 years ago. Your legal opinion for 2023-04 was written about 6 months ago. If they don't agree, my non legal thinking would be to go with the most recent legal opinion, not an old one. I should also point out that your labs article was written entirely about allocations. The legal opinion concerning 2023-04 was entirely about assignments. Very different situations.
more comments inline...
On Wed, 8 May 2024 at 09:30, Maria Stafyla <mstafyla@ripe.net> wrote:
Hi Denis,
Thank you for your comments.
Regarding the processing of the various personal data that might be
inserted in the RIPE Database, please refer to this Labs article where we have outlined which legal ground applies when processing personal data of resource holders and of their contact persons: https://labs.ripe.net/author/athina/how-were-implementing-the-gdpr-legal-gro...
Irrelevant when it comes to End User assignments.
2023-04 policy proposal describes that ‘...It would be more efficient to
remove the ‘solely for the connection’ limitation stated in the current policy, and to allow the creation of a single INETNUM object with status AGGREGATED-BY-LIR, then use this status for dynamic pools, grouping the IPv4 assignments used for the same purpose when they share the same contact information.’
Sorry but this paragraph shows that the legal team has completely misunderstood what 2023-04 was all about. This statement in the proposal was misleading. It suggested the new aggregated status was to handle these dynamic pools. They were already aggregated. The proposal was about aggregating, potentially, all assignments under any allocation.
In the Impact Analysis we are emphasising that, in the event this policy
proposal were to be accepted, it would be up to the member to choose which contact details to insert in their aggregated assignments in the RIPE Database, and that before doing so, they would need to inform the contact persons and get their consent.
This was a confusing part of your analysis. I asked a few times during the discussion on 2023-04 for you to clarify this but you remained silent. The way I read the wording in your analysis was that it is up to the member if they add the details of contact person A or contact person B. This is very different to the policy stating the 'type' of contact whose details must be entered. Maybe the LIR's contact or the End User's contact.
But a clear point here is where you say "they would need to inform the contact persons and get their consent". That is a very clear assertion that personal details for ALL contacts MUST be on the basis of informed and explicit consent. That is not what the current T&C says.
In accordance with the RIPE Database Terms and Conditions, a
‘Maintainer’ is defined as ‘any Registrant or person to whom the authority to Update has been delegated by a Registrant either directly or indirectly, and who holds an identifier that allows updates to be authenticated and authorised.’
This was one of my mistakes. This definition is not correct. For example I am not a Registrant and no Registrant has delegated any authority to me. BUT I can create a PERSON object in the database right now. The database semantics and T&C permit that. Any Registrant can then reference that PERSON object that I created in their resource objects or End User assignments. Who is then responsible and liable for connecting this person with that resource, ensuring consent was given and not withdrawn, and that the personal details are accurate? The definition above does not cover this situation. Also within a large LIR organisation, the staff member who is in contact with the End User customer and who should obtain the consent of the customer to enter their correct personal data into the RIPE Database may not be the same staff member who creates and maintains the objects in the database. So again this definition does not cover this situation.
Article 6.3 describes that the one who holds an identifier and can
therefore update (i.e. enter or remove) information from the RIPE Database ‘must ensure they have as a responsibility to inform the individual to whom the data pertains and to obtain their explicit consent for the entry in the public RIPE Database if required by law.’ Also, according to Article 6.2 they are responsible for ‘keeping all data maintained by them accurate and up-to-date, including correct Contact Details.’
It is more complex than this.
The text in the Impact Analysis is an explanation of how the above rules
are meant to be interpreted. This text does not supersede the RIPE Database Terms and Conditions.
I totally disagree with this suggestion. The IA has to relate to the policy proposal and what will change if that proposal is accepted. In ripe-781 (PDP) it says "The goal of this analysis is to provide relevant supporting information to facilitate discussions on the proposal and provide some projections about the possible impact if it were to be accepted." The IA has nothing to do with how the T&C are interpreted. It should be focused purely on the impact of approving the policy proposal. In your IA statement you made a clear comment about personal data in the RIPE Database that conflicts with the T&C. In this situation I believe that the legal opinion you gave in the IA DOES supersede the T&C.
cheers denis co-chair DB-WG
In our view an update to the RIPE Database Terms and Conditions in this
regard is not needed.
Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC
On Mon, 6 May 2024 at 22:48, denis walker <ripedenis@gmail.com> wrote:
Hi Athina, Maria
It would be nice if one of you can give an update to the community on this issue of the Terms & Conditions being out of step your with current legal opinion.
cheers denis co-chair DB-WG
On Wed, 17 Apr 2024 at 07:36, denis walker <ripedenis@gmail.com> wrote:
Colleagues
In the Impact Analysis (IA) for 2023-04, the RIPE NCC legal team expressed rules for entering personal data into the RIPE Database that are quite different to our previous understanding. This legal IA was relied on heavily by the proposers of 2023-04 and constantly referred to by them during the policy discussions. Based on the discussions and the IA, the chairs of the AP-WG have now approved the proposal 2023-04. We MUST now update the RIPE Database Terms and Conditions to reflect this new understanding on personal data.
In the IA the legal team said this: "Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member’s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date."
Article 6.3 of the RIPE Database Terms and Conditions currently says: "The Maintainer who enters personal data into the RIPE Database has a responsibility to inform the individual to whom the data pertains and to obtain their explicit consent for the entry in the public RIPE Database if required by law."
This article does not accurately reflect the statement in the IA by the legal team. The text "if required by law." must be removed. This suggests that some personal data may not need the 'contact person’s informed and expressed consent'. The IA makes it clear that all personal data entered into the RIPE Database must have the 'contact person’s informed and expressed consent'. There are no exceptions or caveats to this consent. Also the responsibility must not be restricted to the 'Maintainer'. ANYONE has the capability to enter personal data into the RIPE Database. This personal data can then be referenced by a Maintainer of resource data.
I would suggest Article 6.3 says something like this:
"Anyone who updates the RIPE Database with personal data must obtain the contact person’s informed and expressed consent to enter their personal details into a global, freely accessible, public database. This consent cannot be subject to any conditions. If the consent is withdrawn, the personal data must be removed from the RIPE Database in a reasonable time frame. The personal data must be kept accurate and up-to-date. The right to use some Internet resources requires a consenting contact. If no such contact person is available, the right to use some Internet resources may be revoked."
This is a clear and honest statement that fully reflects the IA understanding of the use of personal data in the RIPE Database. I would like to ask the RIPE NCC legal team to make arrangements for this update to the Terms and Conditions.
cheers denis co-chair DB-WG
======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================