[Gnso-epdp-team] Issues with the report
mail at berrycobb.com
mail at berrycobb.com
Wed Feb 13 15:52:25 UTC 2019
Hi Alan and All,
I added one response to the thread below in red.
GNSO Policy Consultant
From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> On Behalf Of Caitlin Tubergen
Sent: Tuesday, February 12, 2019 23:10
To: Alan Greenberg <alan.greenberg at mcgill.ca>; gnso-epdp-team at icann.org
Subject: [Gnso-epdp-team] Issues with the report
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.
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?
BAC: the use of optional has been further expanded in the workbooks. The small team on the workbooks is looking for a better way to present the tables associated with recommendations to more clear represent where and how optional is used. Do note though that the tables represent a consolidated view across the workbooks. If one purpose marks a data element as optional, but it is required in another purpose, the required designation take precedent in the aggregate. From Annex D:
* Optional: - In the Initial Report, those data elements marked as “(optional, (O))”, were used in a generic sense and ultimately caused confusion in how they traversed the processing activities.
* Refined legend: O-RNH, O-Rr, O-CP
* Optional for Registrant to fill in, but if supplied it must be processed
* Optional for Registrar to provide, but if supplied it must be processed
* Optional for contracted party subject to terms and conditions
Please refer to the <https://community.icann.org/display/EOTSFGRD/2019-01-24+EPDP+Team+call+%2339> 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 <https://community.icann.org/display/EOTSFGRD/Meetings+Legal+Committee+Framework?preview=/102138857/102145991/Technical%20Contact%20Memo.docx> 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
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? .
* 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.
BAC: as noted above, the use of “optional” has been expanded and the DET is working on a way to better represent the tables associated with recommendations.
- In Rec #8, why are Tech name and contacts transmitted by registries
to escrow but not by registrars (as currently required by the RAA)?
BAC: workbook 4A has been updated and the Rec#8 has been updated with the existing table, but pending a change in how we present the tables.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnso-epdp-team