[Gnso-epdp-team] FW: EPDP questions for ICANN Org
caitlin.tubergen at icann.org
Wed Oct 3 03:52:13 UTC 2018
Below, please find the recent EPDP questions and answers from ICANN Org.
Marika, Berry and Caitlin
QUESTION: With respect to ICANN’s references to dispute resolution policies within the Temporary Specification, is there a reason only the URS and UDRP were included and not other dispute resolution procedures such as RDDRP, PDDRP and PICDRP?
RESPONSE: The RDDRP, PDDRP, and PICDRP <https://newgtlds.icann.org/en/program-status/pddrp> are dispute resolution procedures where the gTLD registry operators themselves are the respondents. Under the Registrar Transfer Dispute Resolution Policy <https://www.icann.org/resources/pages/tdrp-2016-06-01-en> the respondents are registrars. This is different from URS and UDRP proceedings where individual domain registrants are the respondents. (Note: gTLD registry agreements may also contain other dispute resolution procedures, for example, .NAME has an “Eligibility Requirements Dispute Resolution Policy” <https://www.icann.org/resources/pages/appendix-11-2013-07-08-en>.)
QUESTION: With respect to data retention: For how long and why, should data escrow agents retain old deposits (if at all) in order to fulfill their contractually-required obligations? For how long and why, should data be retained by registries and registrars from the perspective of ICANN Org for purpose A (Establish the rights of a Registered Name Holder in a Registered Name and ensuring that the Registered Name Holder may exercise its rights in respect of the Registered Name)?
RESPONSE: Under the Registrar Data Escrow Specification deposits older than one year must be destroyed, unless a longer period is agreed to by the registrar and the escrow agent. Also, under the base agreement for new gTLDs each escrow deposit must be kept for one year. Legacy gTLD agreements vary; for example the .ASIA, .BIZ, .INFO, and .ORG agreements specify that at least four weeks of deposits must be kept. The purpose of safeguarding a set of prior deposits is to protect registrants in the event a registry or registrar fails or is terminated and the database needs to be reconstituted. In situations where the registration database has to be reconstituted and deposits have not been made in a number of months, safeguarding multiple deposits increases the likelihood that at least one reliable deposit will be available. Also, having multiple deposits increases the likelihood that a reliable deposit is available in the event that the compliance/termination process is contested by the registry operator or registrar. Perhaps registry operators and registrars with operational experience could provide input as to how far back deposits should be kept to ensure that registration databases can be reconstituted when needed.
QUESTION: Apart from ICANN Org Compliance, do any other ICANN departments require access to registration data and, as such, might require a specific purpose? If so, please describe in detail sufficient to provide a legal basis for such data processing.
RESPONSE: This question seems to be asking about any use by ICANN Org of registration data that is now masked pursuant to the Temporary Specification. One example of an ICANN Org activity that previously used WHOIS data elements that may now be redacted pursuant to the Temporary Specification is the WHOIS Accuracy Reporting System, which is currently under review as discussed with the EPDP Team on 26 September 2018. If additional information is needed it would be helpful if the EPDP Team could please clarify if the question is for information related to such past uses of now-masked registration data, or to any current ICANN Org (apart from Contractual Compliance) uses of non-public data, or to any future uses of non-public registration data that may be needed in order to implement GNSO-recommended policies.
Also, in discussions that the EPDP Team has had regarding purposes, ICANN Office of the CTO (OCTO) has been mentioned. To inform the EPDP Team’s continued discussion on this topic, ICANN Org would like to clarify that ICANN OCTO does not require personal data in domain name registration data for its work. For example, OCTO’s Domain Abuse Activity Reporting (DAAR) project <https://www.icann.org/octo-ssr/daar> uses only the registrar and nameserver information.
QUESTION: ICANN Org to provide EPDP Team with copy of agreements with UDRP/URS providers in to demonstrate GDPR compliance in relation to data protection / transfer of data including relevant data protection policies that dispute resolution providers have in place.
RESPONSE: ICANN has used Memoranda of Understanding to govern the relationship with each of the selected URS providers, in which each of the URS providers agree to implement the URS services in accordance with the procedures laid out in the New gTLD Applicant Guidebook, as they might be amended from time to time. Copies of the MOUs are available here: https://newgtlds.icann.org/en/applicants/urs. ICANN does not have agreements or MOUs with UDRP providers. Additional discussion on why ICANN has taken this approach with UDRP providers is available here: https://www.icann.org/en/system/files/files/uniformity-process-19jul13-en.pdf.
In light of the recent changes in data protection laws and the requirements in the Temporary Specification requiring contracted parties to give full registration data to the dispute resolution providers when presented with a complaint if the contact details are not published in WHOIS, ICANN is in discussions with the dispute resolution providers to more fully understand the safeguards they have put in place for the processing of personal data. For example, WIPO has updated its FAQ page concerning the GDPR as it relates to the UDRP: http://www.wipo.int/amc/en/domains/gdpr/, and other providers have reviewed/are in the process of reviewing their supplemental rules in light of changes in privacy laws. ICANN will publish any updates to a provider’s supplemental rules on its website.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4621 bytes
Desc: not available
More information about the Gnso-epdp-team