[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,


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

-------------- 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