[gnso-rds-pdp-wg] Joint Controller / Article 26 / Hamilton Memo

Kris Seeburn seeburn.k at gmail.com
Thu Oct 26 11:09:15 UTC 2017


+1 

That makes sense 

Kris

> On 26 Oct 2017, at 13:12, Paul Keating <Paul at law.es> wrote:
> 
> I agree  Michael,
> 
> However, I am not sure how this moves the ball anywhere since I believe that liability attaches to the processor as well.  A case in point is the actual display of WHOIS data to the public – whether or not it is WHOIS pertaining to a registrant/customer.
> 
> From my point of view I consider WHOIS to be a necessary data set for any number of reasons.  My goal is to find a methodology that allows WHOIS data to be collected and made available with appropriate protections for privacy concerns. By appropriate I mean a system that balances the privacy concerns against the needs of the general public.
> 
> Paul
> 
> 
> From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of theo geurts <gtheo at xs4all.nl>
> Date: Thursday, October 26, 2017 at 8:29 AM
> To: <michael at palage.com>, 'RDS PDP WG' <gnso-rds-pdp-wg at icann.org>
> Subject: Re: [gnso-rds-pdp-wg] Joint Controller / Article 26 / Hamilton Memo
> 
> You are right Michael. 
> 
> Though there is a chance that this is covered more in-depth in part 2?
> 
> Theo 
> 
> On 25-10-2017 23:55, michael at palage.com wrote:
>> Hello All,
>>  
>> I must admit it has been hard to keep up with the flood of recent list traffic.  However, I would like to interject a legal issue raised in the Hamilton Memo which I do not believe has been properly discussed to date. Specifically, Hamilton’s determination that both ICANN and Registration Authorities (Registries and Registrars) are Joint Controllers, see Paragraph 3.4.4 of Hamilton Memo.
>>  
>> Article 26 of the GDPR on the issue of Joint Controller states that “Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers.”  For the purpose of this analysis I will focus exclusively on Registries as well as the fact that there seems to have been a lot of list traffic in connection with the recent actions of .AMSTERDAM and .FRL.  Prior to ICANN, the legacy gTLDs were thin registries. Over the years ICANN has mandated through various RFPs/Applicant Guidebooks the requirement that a TLD be operated in a thick format.   But for a Consensus Policy mandating VeriSign to convert .COM and .NET from thin to thick there was no desire or need for Verisign to have access to this data. How can parties be “joint” controllers, when one party has the unilateral right to impose its will on the other?
>>  
>> I am puzzled why Hamilton made this legal determination and whether it knew of these historical data points. I am also puzzled why Hamilton believes that ICANN as a Joint Controller can unilaterally undertake a DPIA without consultation with the other joint controllers.  I would submit that history and this action, point toward ICANN being the sole Data Controller, and “most” registries being a Data Processor. As evidenced by VeriSign, most gTLD registries do not need thick data to perform their core business functions. They are only deemed a Joint Controller because ICANN has mandated that they collect and process the PII of registrants.
>>  
>> I would welcome any additional insight on this Article 26 issue.
>>  
>> Best regards,
>>  
>> Michael
>>  
>>  
>> 
>> 
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> 
> _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg at icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171026/e669d0e7/attachment.html>


More information about the gnso-rds-pdp-wg mailing list