[ALAC] EPDP Early input

Alan Greenberg alan.greenberg at mcgill.ca
Wed Aug 29 15:40:51 UTC 2018 

GDPR does allow for this, but the data 
commissioners have said they do not care. I 
believe we can make arguments that shift that 
balance and I certainly feel we need to try.

Alan

At 29/08/2018 09:35 AM, John Laprise wrote:
>While ICANN's situation is unusual, GDPR doesn't 
>care. The greatest benefit as a nonprofit is 
>that ICANN can assert "legitimate interest" more 
>readily than a for profit. However, as I 
>mentioned, legitimate interest rests on a 
>balancing test between the interests of a PII 
>subject and the data controller. There are many 
>cases where where individual interests outweigh ICANN's.
>
>On Wed, Aug 29, 2018, 2:06 AM Seun Ojedeji 
><<mailto:seun.ojedeji at gmail.com>seun.ojedeji at gmail.com> wrote:
>Sent from my mobile
>Kindly excuse brevity and typos
>
>On Wed, 29 Aug 2018, 03:35 Alan Greenberg, 
><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca> wrote:
>I'm not at all sure that our situation is 
>comparable. It is certainly far more atypical 
>than a standard business or nonprofit.
>
>Most people who have more knowledge of GDPR that 
>I do deem ICANN to ba a controller, although 
>perhaps a join controller. But an unusual one in 
>that unlike most controllers, we do not actually have custody of the data.
>
>Regarding where we are going on this, I am not 
>prepared to roll over an just play dead. I think 
>we need to put up a fight to get where we need 
>to be. For instance, there are those who are 
>saying (and using the data commissioners words 
>to "prove" it, that we must not consider any 
>needs other than our own. I differ on this. 
>ICANN is not just responsible for making sure 
>that the DNS records are orderly. We also have a 
>responsibility to ensure that the DNS is usable 
>and trusted. Although the ICANN mission does not 
>use that word in this context, I believe that an 
>untrusted DNS may as well not be there and be 
>replaced with some other mechanism. GPDR DOES 
>allow us to consider the needs of others. 
>Article 6.1(f) explicitly says so. It is not 
>unlimited but it is there and should allow us to 
>make the case for ensuring that law enforcement 
>and cyber security workers can get access. That 
>is part of our job in this game.
>
>And like some of the SAC101 recommendations, we 
>need to not only make sure that the data is 
>there, and accessible, but that it can in 
>practice be accessed (such as recommendations on RDAP and rate limiting).
>
>
>SO: Agree
>
>The Temporary Spec is overreaching in that it 
>says we are responsible for the entire framework 
>for such activities and that is nonsense,
>
>
>SO: By "we" I believe that ICANN is referred 
>here, my question to you then is if ICANN is not 
>who else should responsible for that? (at least on high level basis)
>
>
>but I believe that we do have a responsibility 
>to ensure that we support that framework and 
>ensure that some types of data are available.
>
>
>SO: While I agree with the principle of support 
>from ICANN, may I know who you believe should prepare the framework?
>
>Regards
>
>
>If that is not why we are on the EPDP, then I 
>hope someone will tell me that so I can save myself an awful lot of work.
>
>Alan
>
>
>At 28/08/2018 08:44 PM, Holly Raiche wrote:
>>Thanks John
>>
>>It’s really helpful hearing from someone who 
>>has to implement GDPR - and can bring those insights to the table.
>>
>>I think we all struggle to work through - first 
>>- whether ICANN is the data processor or 
>>controller, and from there, what information is 
>>actually required by whom, used by whom and accessed by whom.
>>
>>If there were an easy answer, I think we’d be 
>>there.  But none of this is easy, so this insight is really welcome.
>>
>>Thank you
>>
>>Holly
>>On 29 Aug 2018, at 10:37 am, John Laprise 
>><<mailto:jlaprise at gmail.com>jlaprise at gmail.com> wrote:
>>
>>>So in my day job I was one of the GDPR 
>>>implementation leads and we’ve just wrapped 
>>>up the initial work. We were assisted by an 
>>>external consultancy. That said, if anything SSAC did not go far enough.
>>>
>>>ICANN has a contractual basis for data 
>>>collection related to the contracts it signs. 
>>>The claim of legitimate interest is stretched 
>>>well beyond it’s intent and in fact the EU 
>>>has opined on the balancing test required. My 
>>>understanding of the balancing test would call 
>>>into question even legitimate law enforcement 
>>>requests where the PII was of an individual or 
>>>organization known to be persecuted. In that 
>>>case, couldn’t exert legitimate interest if it fails the balance test.
>>>
>>>I am sympathetic to the needs of security 
>>>researchers and law enforcement but ICANN data 
>>>collection does not exist for them, though it 
>>>is used by them. The proper scope is 
>>>identifying what data SSAC and RSAC need and use to advance ICANN’s mission.
>>>
>>>While rationale for data collection is one 
>>>pain point, another that my org discover was 
>>>in terms of data transfer/processing. 
>>>Legitimate interest is not recognized 
>>>rationale there. Moreover as a US nonprofit 
>>>ICANN is ineligible for PrivacyShield which could give it some cover.
>>>
>>>Finally and perhaps to make matters worse, the 
>>>technical spec instruct registries on data 
>>>collection. I confess that at this point I’m 
>>>not sure whether ICANN is acting as a data 
>>>controller or a data processor. In a sense, 
>>>the registries are data controllers and ICANN 
>>>is the data processor, thrusting the onus of compliance upon registries.
>>>
>>>I’m at the limits of my GDPR for the day so 
>>>additional thoughts would be welcome.
>>>
>>>Best,
>>>
>>>John
>>>
>>>From: ALAC 
>>><<mailto:alac-bounces at atlarge-lists.icann.org> 
>>>alac-bounces at atlarge-lists.icann.org> On Behalf Of Holly Raiche
>>>Sent: Tuesday, August 28, 2018 2:17 PM
>>>To: Marita Moll 
>>><<mailto:mmoll at ca.inter.net>mmoll at ca.inter.net> 
>>>; ALAC <<mailto:alac at atlarge-lists.icann.org> alac at atlarge-lists.icann.org>
>>>Cc: Alan Greenberg 
>>><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca >
>>>Subject: Re: [ALAC] EPDP Early input
>>>
>>>Thanks Marita
>>>
>>>I like your wording.  Ys it is a big document 
>>>and I like your wording as to wha it is in the report that we endorse.
>>>
>>>Holly
>>>On 29 Aug 2018, at 1:18 am, Alan Greenberg 
>>><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca > wrote:
>>>
>>>Marita, I am not sure that your synopsis is 
>>>all that different from endorsing the entire 
>>>paper when you start examining the rationales, 
>>>but I would be happy to accept that if we can 
>>>get closure on it quickly. Time is our enemy in this overall EPDP process.
>>>Alan
>>>At 28/08/2018 10:38 AM, Marita Moll wrote:
>>>
>>>
>>>Sorry to have missed the call -- still 
>>>confusing midnight Monday with midnight 
>>>Tuesday -- I guess I will get used to the format.
>>>I just read this really well done SSAC report 
>>>which is clear and thorough. But there is a 
>>>lot in there. I wonder if we should do a 
>>>blanket endorsement of everything without careful analysis.
>>>Could we not have a more nuanced position? For 
>>>example, we could say that, in line with our 
>>>mandate to support end-users, we support 
>>>SSAC's position on ensuring that security 
>>>professionals and law enforcement have adequate access to WHOIS/RDS data.
>>>If that is the point we want to make.
>>>Marita
>>>On 8/28/2018 2:23 AM, Alan Greenberg wrote:
>>>
>>>As I mentioned on the ALAC call that has just 
>>>completed, all EPDP participant groups have 
>>>been given the opportunity to provide "early input" into the EPDP.
>>>So far, the SSAC and the NCSG has done so. 
>>>Their input can be found 
>>>at<https://community.icann.org/x/Ag9pBQ>https 
>>><https://community.icann.org/x/Ag9pBQ>://community.icann.org/x/Ag9pBQ.
>>>The SSAC's input consisted of their recent 
>>>report SAC101. A copy is attached for your convenience.
>>>I would like to suggest that the ALAC submit a 
>>>statement saying that we support SAC101, as it 
>>>is in line with our stated position of trying 
>>>to ensure that security professionals and law 
>>>enforcement have adequate access to WHOIS/RDS data.
>>>I open the floor for discussion and will 
>>>initiate a Consensus Call later in the week.
>>>Alan
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>
>>>
>>>
>>>
>>>
>>>ALAC mailing list
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>><mailto:ALAC at atlarge-lists.icann.org>
>>>
>>>ALAC at atlarge-lists.icann.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>https://atlarge-lists.icann.org/mailman/listinfo/alac
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>At-Large Online:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>http://www.atlarge.icann.org
>>>
>>>
>>>
>>>
>>>
>>>ALAC Working Wiki:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>>>_______________________________________________
>>>ALAC mailing list
>>><mailto:ALAC at atlarge-lists.icann.org>ALAC at atlarge-lists.icann.org
>>>https://atlarge-lists.icann.org/mailman/listinfo/alac
>>>At-Large Online: 
>>><http://www.atlarge.icann.org/>http://www.atlarge.icann.org
>>>ALAC Working Wiki: 
>>><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC 
>>>)
>>>_______________________________________________
>>>ALAC mailing list
>>><mailto:ALAC at atlarge-lists.icann.org>ALAC at atlarge-lists.icann.org
>>>https://atlarge-lists.icann.org/mailman/listinfo/alac
>>>At-Large Online: 
>>><http://www.atlarge.icann.org/>http://www.atlarge.icann.org
>>>ALAC Working Wiki: 
>>><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC) 
>>>
>_______________________________________________
>ALAC mailing list
><mailto:ALAC at atlarge-lists.icann.org>ALAC at atlarge-lists.icann.org
>https://atlarge-lists.icann.org/mailman/listinfo/alac
>
>At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org
>ALAC Working Wiki: 
><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20180829/354735aa/attachment.html>

More information about the ALAC mailing list