Olivier My fault - it should be on whatever list is appropriate. PLEASE share it with EURALO or whomever. The problem was lack of time and I felt we had to do something - ‘feedback’ is due 29 Jan - and I wanted to start an open discussion . Aida, Vanda, Carlton and Alan have already made comments by email - my hope, by asking for a wiki - was to centralise the discussion. And now that Jonathan has put his hand up, he can take it from here. I”ll put the stuff I said on the wiki, just to start the discussion. And please scold me - my fault. But then please, get EURALO to comment as well Holly On 20 Jan 2018, at 11:27 am, Olivier MJ Crépin-Leblond <ocl@gih.com> wrote:
Hello all,
now I really do not know what to make of this. Once again we have a substantial policy discussion on the ALAC Internal List and now an announcement of a WIKI workspace being created. As a result, I do not know if I can share this with my EURALO constituents - and the debate is yet again within the 15 member ALAC & whomever is on the ALAC Internal List. Not very inclusive, is it? In the meantime, the open At-Large mailing list is seldom used for any policy discussion of value, even though whenever someone sends such a discussion out, there is movement on the list.
Meanwhile, announcements of RALO appointees, whether for Onboarding or Leadership Training, are also made on the ALAC Internal, so I receive emails from interested parties and applicants asking me what is going on, up to several days after a choice and an announcement are made.
Why so much hiding?
Olivier
On 19/01/2018 15:15, Evin Erdogdu wrote:
Hello Holly and All,
Please see the created wiki workspace for Data Protection and Privacy Update - Community Feedback on Proposed Compliance Models.
Feedback is requested by 29 January 2018.
Kind Regards, Evin
From: Holly Raiche <h.raiche@internode.on.net> Date: Thursday, January 18, 2018 at 6:41 PM To: ALAC Internal List <alac-internal@atlarge-lists.icann.org> Cc: ICANN At-Large Staff <staff@atlarge.icann.org> Subject: [Ext] ALAC comments on ICANN models for GDPR
Folks
First - we really need a wiki space on our policy page so that we can collect any comments on ICANN’s models responding to the GDPR. At the moment, Alan, Carlton, Vanda and Aida have all made comments - but they are not in one place and should be. “Feedback’ is due 29 January, so if ALAC is to say something - we should all agree on what that is - and it should all be in one place so everyone can view all of the comments together.
Next, I’ve finally had a good look at the document and offer the following comments:
General comments: Any model adopted should, as much as possible, be close to a position that everyone is comfortable with. The reality is that actually changing the current RDS policy (i.e., requirements in the RAA on the collection and public access to registration data) will take at least another couple of years (The current RDS WG is only at the first stage of the policy change needed - 18 months after it started at least). So this ‘interim’ model will be used for a significant amount of time before it is replaced. Further, if we are calling on registrars/registries to adopt a model now, it should be as close as possible to the ultimate solution so that registries/registrars don’t have to change their systems yet again. ( I recognise this is called an ‘interim’ solution: the reality - it will be a long ‘interim’) A related point - any policy adopted should be one that applies globally. There should not be a policy that gives one part of the globe a level of privacy protection that does not apply elsewhere. And on a more practical note, how does a registrar or registry be sure of whether all of their customers live in an area that attracts one level of privacy protection or another. The basis of any model adopted should be on privacy principles. Yes, the GDPR is the most stringent, but we need to recognise that data protection legislation has been enacted globally, based on fundamental OECD principles. Those principles include the direction that data collectors must only collect information - particularly personal information - that is necessary for them to carry out their function(s), that the data collector must - up front - tell the data subject the purposes to which the data will be put and the circumstances in which defined others will access the data. The final document should use the language of SSAC51 - for the data itself, the service and the protocol. Using ‘Whois’ leads to confusion as to what is being referred to Specific comments: Approach- Clause 6: Agree with the statement that all of the compliance models are based on tiered access - and agree with tiered access Commonalities - Clause 1: I am not sure we should agree with the statement that registrars may collect (but not necessarily publish) all of the personal data elements currently in the Thick registration data. This is an issue that the RDS WG is working through - to determine what information is actually necessary for the the registrars/registries to carry out their functions. However, I accept that this may be too hard for anyone outside of the WG discussions to come to final agreement upon Purpose Description - Purpose of Whois. This text confuses two things. The purpose of ICANN is about coordination, stability etc of the Internet’s unique identifier system. But the purpose that is critical here is the purpose of the collector - the registrar. So the tests for whether the information should be collected is whether the registrar needs the information to carry out their functions Models - General.Only Models 2B and Model 3 apply globally. On that basis, reject Models 1 and 2A Model 2A vs Model 3: In Model 2A - the name of the registrant is only displayed with the consent of the registrant (whether a natural person or company), access to non-public data would be to a defined set of third party requesters under a formal accreditation/certification program (this could include law enforcement agencies, certified intellectual lawyers, etc based on pre-defined criteria and as part of a formal accreditation process. As an interim measure, self certification could be used as part of an interim mechanism In model 3, the registrant’s name would be displayed (with or without consent), and not publish personal data. However, this would require assessment on a field by field basis as to whether personal data would be included. There would be a stricter regime for access - only under applicable law and subject to due process requirements such as under subpoena or oner judicial order. My recommendation: Go with either Model 2B or 3. Model 3 is the stricter, but appears to be a bit complex in its assessment against each field. Certainly there are very tight controls on access to the data. Model 2A has the possibility of more access - based on pre-determined requirements/accreditation. The timeframe for data retention under both is also different (life of registration +1 year for 2A, and +60 days)
My personal choice - Model 2A - as long as there is a tight accreditation process, and tightly defined criteria for who (already accredited) gets access to personal information in what circumstances. But this is for ALAC members to decide.
Holly
_______________________________________________ ALAC-Internal mailing list ALAC-Internal@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac-internal
ALAC Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
At-Large Website: http://atlarge.icann.org