[ALAC] EPDP Early input

Wed Aug 29 07:06:15 UTC 2018

Sent from my mobile
Kindly excuse brevity and typos

On Wed, 29 Aug 2018, 03:35 Alan Greenberg, <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 <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 < alac-bounces at atlarge-lists.icann.org> *On Behalf Of *Holly
> Raiche
> *Sent:* Tuesday, August 28, 2018 2:17 PM
> *To:* Marita Moll <mmoll at ca.inter.net>; ALAC <
> alac at atlarge-lists.icann.org>
> *Cc:* Alan Greenberg <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 <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 <https://community.icann.org/x/Ag9pBQ>
> ://community.icann.org/x/Ag9pBQ <https://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
>
>
>
>
>
>
>
>
> 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
> 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
> 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
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20180829/ed79389e/attachment.html>