[ALAC] EPDP Early input

Wed Aug 29 15:38:17 UTC 2018

See embedded.

At 29/08/2018 03:06 AM, Seun Ojedeji 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)

AG: I suspect we will find that there is no one 
who is responsible, and that indeed there is no 
unified single "framework". But there are 
aoperational processes and it is to thatose that 
I beleive we need to ensure the availability of salient information.

>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/14d59b95/attachment.html>