[Gnso-epdp-team] Issues with the report

Wed Feb 13 04:10:29 UTC 2019

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 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. 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/646df0c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190213/646df0c6/smime-0001.p7s>