[ALAC] GDPR on today's ALAC Agenda

[Sebicann Bachollet]

FYE
https://www.icann.org/en/system/files/correspondence/marby-to-denham-26mar18-en.pdf <https://www.icann.org/en/system/files/correspondence/marby-to-denham-26mar18-en.pdf>
SeB

> Le 27 mars 2018 à 22:10, Holly Raiche <h.raiche at internode.on.net> a écrit :
> 
> Actually Alan - the most important question - because it has not yet been decided - is the accreditation model.
> 
> Who develops it - why just privacy experts and the GAC
> Should it be voluntary or mandatory
> What about the Code of practice suggested - voluntary or mandatory
> should there be just one category for everyone who gets access - or more categories (e.g., law enforcement gets all, others get some in certain circumstances?
> As I said, these are the GDPR issues that the Model indicates have NOT been the subject of ICANN Org's conclusion and where we can still make a difference
> 
> Holly
> 
> On 28 Mar 2018, at 5:50 am, Alan Greenberg <alan.greenberg at mcgill.ca <mailto:alan.greenberg at mcgill.ca>> wrote:
> 
>> Attached and in the body of this message are the notes for today's discussion of GDPR on the ALAC Call.
>> 
>> -----------------------------
>> 
>> ALAC Meeting – 27 March 2018 – GDPR Discussion
>> 
>> The ALAC and At-Large are divided on whether the proposed Interim Model meets the requirements of the GDPR and specifically whether the rationales for collecting various data items are specified in sufficient detail and are sufficiently compelling. There are also differing views on whether the transport of data to Registries in compliance with "thick WHOIS" rules is GDPR compliant. In the absence of concerns over privacy, ICANN has previously determined that the thick WHOIS model is the one that should be used and we should not re-litigate that here. We have similarly decided that single points of failure must be avoided and all data must be escrowed in case of any of multiple forms of failure. All data items have proven useful in the past (that was the result of ICANN's earlier work). Whether it can be justified in the current situation is the question.
>> 
>> All of these issues will need to be judged by DPAs and to the extent that they make clear statements, we will have to abide by them.
>> 
>> The ALAC has the responsibility to look at all issues from and end-user perspective. We also have concerns for registrant issues, but where they differ we support users.
>> 
>> 1. Must registrars continue to collect the contact details for administrative and technical contacts and transmit them to the registry and escrow provider?
>> 
>> 2. Should anonymized e-mail addresses should be substituted for the e-mail addresses for registrant, administrative, and technical contacts in public WHOIS?
>> 
>> 3. Should registries and registries be permitted to optionally apply the model on a global basis?
>> 
>> 4. Should the model apply to contact details supplied by registrants who are legal persons?
>> 
>> 5. Which elements of WHOIS data should be published in public WHOIS while an accreditation program for layered/tiered access is being developed?
>> 
>> 6. How many levels should the "tiered" access mechanism support?
>> 
>> 7. Bulk access – should it be allowed?
>> 
>> <GDPR-20180327.pdf>_______________________________________________
>> ALAC mailing list
>> ALAC at atlarge-lists.icann.org <mailto: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/20180328/0b87a141/attachment.html>