[ALAC] [ALAC-Internal] Wikispace Created - Re: [Ext] ALAC comments on ICANN models for GDPR
Olivier MJ Crépin-Leblond
ocl at gih.com
Sat Jan 20 10:52:28 UTC 2018
Dear Holly,
thanks for the explanation. I'll forward to EURALO.
Kindest regards,
Olivier
On 20/01/2018 06:11, Holly Raiche wrote:
> 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 at gih.com
> <mailto:ocl at 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
>>> <https://community.icann.org/display/alacpolicydev/At-Large+Workspace%3A+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 at internode.on.net>
>>> *Date: *Thursday, January 18, 2018 at 6:41 PM
>>> *To: *ALAC Internal List <alac-internal at atlarge-lists.icann.org>
>>> *Cc: *ICANN At-Large Staff <staff at 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 collecto_r - 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_:
>>>
>>> o 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
>>> o 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 at 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+(ALAC)
>>>
>>> At-Large Website: http://atlarge.icann.org
>>
>>
>
--
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20180120/493db29b/attachment.html>
More information about the ALAC
mailing list