This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] 2022-01 V2 Resource Holders Address
- Previous message (by thread): [db-wg] 2022-01 V2 Resource Holders Address
- Next message (by thread): [db-wg] 2022-01 V2 Resource Holders Address
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Fri Jun 24 08:02:21 CEST 2022
In message <CAKvLzuEE8494HY3OS6Byy1SQ+BJ=c576sgTW=r9fm7dQK5mbDw at mail.gmail.com> denis walker <ripedenis at gmail.com> wrote: >> First and foremost, if in fact there exist such telecom companies, then >> -somebody- should be able to give us their names. I'm still waiting. >> I haven't seen -any- names of any such supposed telecom companies yet. >> > >AFAIK the names of these organisations is not public information, only >anonymous statistics have been published. If you have an issue with this I >suggest you discuss it directly with the RIPE NCC legal team. Thank you for that helpful suggestion. I feel certain that RIPE legal will be instantly forcoming with the names, just as RIPE legal has always been with regards to all other such particular inquiries. :-) Unfortunately, I cannot engage RIPE legal on this matter at the present time because I am stuck in a non-interruptable wait loop, waiting for Donald Trump's legal team to get back to me and to provide me with the evidence that they assure me really and truly does exist, and that proves that massive election fraud took place in the 2020 U.S. Presidential election. >> Second as was previously discussed, responsiblity, both legal and otherwise, >> for any unnecessary "leakage" of PII under GDPR belongs to the party that >> first leaked the data. So if some telecom company is carelessly shoveling >> their customer PII into the RIPE data base in a way that is not consistant >> with GDPR then the entire legal responsibility for that belongs to the telecom >> companies involved... *not* to RIPE. It is therefore quite obviously false >> to continue to insist that RIPE needs to take some action because of these >> specific companies or these specific WHOIS records. It doesn't. > >This policy proposal is not about managing the legal responsibilities or >liabilities of the RIPE NCC. Well, you could have fooled me! If this proposal has nothing to do with legal responsibilities or liabilities, then why do you keep on mentioning GDRP as a justification for this? And why does the proposal itself contain the following telling verbiage? "Now the EU General Data Protection Regulation (GDPR) adds legal constraints on personal data and the justification for its use." >> Third and lastly, underlying these arguments is a sort-of implicit and >> unspoken assumption that simply is not true and that can quite easily >> disproven, i.e. the obviously flawed assumption that the RIPE region is >> synomymous with the EU and/or the EEA and that thus, GDPR applies >> throughout the RIPE region. It doesn't. > >The RIPE NCC is the data controller... No, it isn't. You are simply misinterpreting the definition of "controller" in the actual GDPR legislation. RIPE is *not* the entity that receives the PII in the first instance, and it is thus *not* the "controller" as per GDPR. You need to go back and re-read the definition of "controller" in the actual legislation. >> In addition to such notable and significant countries as Russia, Ukraine, >> and Turkey, it appears that there exist a whole raft of other >> countries also that are -in- RIPE but -outside- of EU/EEA, for example >> Aland Islands, Albania, Andorra, Armenia, Azerbaijan... and that's just >> the As! I'm sure that there are plenty more also. Companies and natural >> persons in these countries are not bound by GDPR, despite the fact that >> some would wish it to be so. Thus companies and persons outside of EU/EEA >> remain free to put whatever they like into the RIPE WHOIS data base, and >> RIPE is free to publish whatever they do put in there, as has already been >> discussed and agreed here. (Note that the Personally Identifiable Information >> involved in many of these cases will pertain to natural persons who themselves >> reside -outside- of the EU/EEA area, and GDPR is simply not applicable to >> the PII of any such persons.) > >There are Russian lirs who provide address space and services to end users >based in the Netherlands. Irrelevant and immaterial. RIPE is *still* neither the data "controller" nor the data "processor" as per the definitions of these terms in the GDPR legislation, regardless of the location of the legal entity that gives the data to RIPE. (That entity, whoever it is and wherever it is, is the data "controller"... *not* RIPE.) Regards, rfg P.S. Here is the public data from my own domain name WHOIS record for my own domain, tristatelogic.com: Registrant Name: Ronald F. Guilmette Registrant Street: 1751 E Roseville Pkwy Registrant Street: Apt 1828 Registrant City: Roseville Registrant State/Province: CA Registrant Postal Code: 95661 Registrant Country: US Registrant Phone: +1.9167867945 Registrant Email: rfg-dynadot at tristatelogic.com Ten seconds after I hit send on this email, the above data will be placed into the *public* web-accessible mailing list archive for this Working Group... a public archive which is operated and maintained by RIPE and within the EU region. In short, ten seconds after I hit send on this email, RIPE will be publishing, to the entire world, a great deal of *my* Personally Identifiable Information (PII). By your logic, eleven seconds after I hit the send button, I will have a perfectly valid and viable legal cause of action against RIPE for publishing my private information, which RIPE will be doing in violation of GDPR. This is the demonstratably absurd outcome that arises, inevitably, from your misunderstanding of GDPR's definitions of the key terms "controller" and "processor".
- Previous message (by thread): [db-wg] 2022-01 V2 Resource Holders Address
- Next message (by thread): [db-wg] 2022-01 V2 Resource Holders Address
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]