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 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
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@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@icann.org] On Behalf Of Caitlin Tubergen Sent: Wednesday, February 13, 2019 6:10 AM To: Alan Greenberg; gnso-epdp-team@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+Framew...>. 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
Hi Alan and All, I added one response to the thread below in red. GNSO Policy Consultant @berrycobbb From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Caitlin Tubergen Sent: Tuesday, February 12, 2019 23:10 To: Alan Greenberg <alan.greenberg@mcgill.ca>; gnso-epdp-team@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? 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+Framew...> 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. 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. Alan
Thanks Caitlin. Sorry for delay in replying. See comments below on Rec #8.. At 12/02/2019 11:10 PM, Caitlin Tubergen wrote: - 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+Framew...>. This response has also been documented in the Final Report. AG: I am not sure that the permission of the contact is relevant since any e-mail address published would be anonymized. Nevertheless, there are industry-standard methods for the registrar to get such approval - it is used pretty much every time you subscribe to a mailing list and for many other transactions. You send an e-mail to the address confirming that they accept using their address. My problem here is that as you say, the group WAS divided. Typically in that case we either accept the status quo (what is done today or in the Temp Spec). Instead we took an option that was favoured by one part of the group for which there is no precedent.
participants (4)
-
Alan Greenberg -
Caitlin Tubergen -
Hadia Abdelsalam Mokhtar EL miniawi -
mail＠berrycobb.com