[Gnso-epdp-team] Issues with the report

Wed Feb 13 12:42:00 UTC 2019

Dear All,

I have two comments with respect to the technical contact and the geographic based differentiation

Two points with regard to the technical contact
First the technical contact does not need to be personal information example tech at company.com
Second the registrar can easily notify the technical  contact - within one month from registration or before the first contact with the data subject - because it has the contact information on file and thus will have a means to demonstrate that in fact a notice has been provided.

Therefore if registrars inform data subjects that the technical contact should not be personal information and
put  a system in place to notify the technical contact upon registration there should be no significant risk. In all cases registrars that decide to offer the technical contact are going to rely on methods that educate the data subject and notify the third party that is they are going to put a complying process in place.

With regard to geographic distinction - recommendation #16 - since we did not receive yet the legal advice in this regard
We could amend recommendation #16 to say  " registrars are not obligated to do so now and until further legal advice has been received and discussed during phase II of the EPDP team work. Work of phase II may compliment or replace this recommendation "

Have a nice day

hadia

From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org] On Behalf Of Caitlin Tubergen
Sent: Wednesday, February 13, 2019 6:10 AM
To: Alan Greenberg; gnso-epdp-team at icann.org
Subject: [Gnso-epdp-team] Issues with the report

Hi Alan,

Please find answers to your questions in blue.

We are still looking into one of your questions, but noting the request for a quick reply, please see the answers below.

Thank you.

Best regards,

Marika, Berry, and Caitlin
--

There are several issues with the report that are either incorrect,
or I do not know how the decisions were made (and several others also
do not know).

- Rec #8 implies (but does not clearly say) that offering Tech
Contacts is an option for registrars. In the interim report, we
raised the question of whether "optional" for the Tech fields meant
optional for the registrant, or optional for the registrar. I cannot
recall ever discussing this when we went over the comments, but
somehow it is now optional for registrars, requiring registrants to
shop around for a registrar that accepts the option - if indeed any
registrars will! When was this decided?

Please refer to the 24 January meeting<https://community.icann.org/display/EOTSFGRD/2019-01-24+EPDP+Team+call+%2339> as well as the response from Bird & Bird re: the liability associated with additional contact information.

As you may remember, there was an “informal vote” at the end of the 24 January call, during which there was no consensus with respect to the meaning of “optional”. In other words, approximately half of the groups preferred optional to mean the registrar has the option of offering a technical contact field to the registrant, and half of the groups preferred optional to mean the registrar must offer the technical contact field but the registrant has the option of providing contact information for the technical contact field.

We noted, during the call, that we would document the status of the issue in the Final Report and await further legal advice.

The following question was posted to legal counsel:

The EPDP Team also took note of a related footnote [from the EDPB] which states, “[if contact details for persons other than the RNH are provided] it should be ensured that the individual concerned is informed”. The EPDP Team discussed whether this note implies that it is sufficient for the Registered Name Holder (RNH) to inform the individual it has designated as the technical contact, or whether the registrar may have the additional legal obligations to obtain consent. The EPDP Team requested external legal counsel guidance on this topic who provided the following summary answer:

Legal Counsel provided the following response:

“In cases where the RNH and the technical contact are not the same person, relying on the RNH to provide notice on the registrar's behalf will not meet GDPR's notice requirements if the RNH fails to provide the notice. While this may provide grounds for a contractual claim against the RNH, it is unlikely to provide a viable defence under the GDPR. Moreover, this arrangement will make it difficult for registrars to demonstrate that notice has been provided. If notice is not effectively provided, this could affect the legitimate interests analysis, since technical contacts may not "reasonably expect" the manner in which their data will be processed. If relying on consent, such an arrangement would make it difficult to document that consent has been provided”.

If you would like to refer to the full response from Bird & Bird, please refer to the this memo<https://community.icann.org/display/EOTSFGRD/Meetings+Legal+Committee+Framework?preview=/102138857/102145991/Technical%20Contact%20Memo.docx>. This response has also been documented in the Final Report.

- Rec #16 takes geographic differentiation off the table. My
recollection is that we put that decision into Phase 2. When was this
decision taken?

Please refer to the email from Marc A. (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001543.html), which includes the text that is now in the Final Report. Feedback was requested, following a number of positive responses to this approach (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001485.html) - no objections were raised at the time; however, if your group believes this is in error, please flag this accordingly.

Please also note the following question has been posed to legal counsel:

In light of the EDPB Guidance on territorial scope of GDPR, how do ICANN’s stable establishments within the EU impact its responsibilities as a data controller. The EDPB Guidance appears to suggest that ICANN, as a controller with stable establishments within the EU, might be required to comply with GDPR? Is this the case even if the majority of processing activities (including registrar/reseller collection of data from RNH) take place outside of the EU? .

Specifically:

  *   Do any of ICANN’s operations within the EU qualify as Establishments, as defined by Recital 22 of the GDPR?
  *    If ICANN is found to have Establishments within the EU, do these Establishments require ICANN (as a controller of gTLD Registration Directory Services related processing activities) to be subject to article 3.1 of the GDPR?
  *   Do the answers to the above questions impact ICANN’s, and/or any associated controllers’ or processors’, ability to distinguish between Registered Name Holders (RNH)/data subjects based on the geographic location of the RNHs in determining the geographic scope of GDPR?

- Rec #18 does not make sense to me. It says that Temp Spec sections
4.1 and 4.2 are to be replaced "upon expiration". What is the purpose
of replacing these sections once the Temp Spec is no longer
operative? And how does that affect access? I note that Rec #28
temporarily reinstates the Temp Spec, but the version PRIOR to expiration.

The work of the EPDP Team is to confirm, or not, the language in the Temporary Spec. In some cases, the Team confirmed the precise language in the Temporary Specification. Per the feedback of the EPDP Team, rather than simply confirming language, we have inserted the specifically-agreed upon language within the Temporary Specification into the Final Report.

In the case of Recommendation 18, the Team agreed to replace the language in the Temporary Specification with the language noted in the recommendation, noting that work in Phase 2 may complement or replace the language within the recommendation. The Team agreed these new defined criteria would be effective as soon as the Temporary Specification expires, which is why it is denoted as such.

- Rec #29 requires explicit action from registrars before the Admin
fields can be eliminated. Either we need to explicitly say that this
action must be taken prior to 29 February 2020, or we need to include
them in Rec #5 listing all RDDS fields flagging them as being there
only until the Rec #29 action is taken.

Thank you for flagging this. We could add a sentence that this action must be taken prior to 29 February 2020 if the EPDP Team agrees.

On a less substantive level:

- We say the Tech name and contact fields are option, but in the
various tables, the are not flagged with a trailing (opt.) like the
other optional fields are.

- In Rec #8, why are Tech name and contacts transmitted by registries
to escrow but not by registrars (as currently required by the RAA)?

We are looking into this and will revert to you shortly.

- Rec #13 makes a reference to "Recommendation X". I presume this
should be Rec #6.

Yes, thank you for noting this.

- Rec #21 makes reference to Thick and Thin registries, a concept
that we are told no longer exists.

The language you reference is part of the Temporary Specification that the Team agreed to confirm at its face-to-face meeting in Toronto. Please refer to Annex D of the Temporary Specification.

The first issues have a direct bearing on whether the ALAC can
support this report and I would appreciate a quick reply.

Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190213/6c6e84af/attachment-0001.html>