Public Comment CloseStatement



Call for
Comments Open
Call for
Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number

13 October 2018


15Y, 0N, 0A

12 October 2018

13 October 2018

15 October 2018

18 October 2018

13 October 2018


Hide the information below, please click here 


The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 

Update with ALAC Consensus from ICANN63:


The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

The At-Large Advisory Committee (ALAC) recommends that ICANN adopt the Registration Data Access Protocol (RDAP) quickly and effectively because it is an essential step for ICANN to deploy a tiered-access model adequately. RDAP implementation, in turn, puts ICANN in a better position to be more compliant with the European Union's General Data Protection Regulation by ameliorating the relevant deficiencies to the contemporary WHOIS model. As the community is aware, the current WHOIS seven-bit ASCII system cannot hold international registration information (e.g., name or address) and that, in turn, leaves the entire DNS community, including end-users, vulnerable to various online threats. RDAP is a solution ICANN has long had to resolve these issues and the At-Large implores its wide adoption expeditiously to resolve these matters.


Additionally, the ALAC appreciates the RDAP's revised structure that intends to distinguish the policy-independent elements and policy-dependent elements. Assuming the RDAP Profile appropriately defines such distinctions, this will ensure that ICANN removes the technical implementations of the RDAP from political considerations and debate, and, as a result, not bog down its adoption.


In its current form, the RDAP appears to emulate some of the ambiguities that exist within key provisions of the European Union's (EU) General Data Protection Regulation (GDPR), and it would behoove ICANN to address these concerns as it moves through RDAP's implementation.  Examples of such ambiguities are:  

  • What constitutes a "legitimate purpose" as it is articulated in Para. 4.4, particularly as it relates to the notion of "accurate reliable and uniform (...) based on legitimate interests not outweigh by (...) fundamental rights";
  • the framework to address appropriate law enforcement needs under Para. 4.4.9;
  • handling contractual compliance monitoring requests under para. 4.4.13;
  • provisions in Annex A para. 4 that requests operators to "provide reasonable access to [data] to third parties on the basis of legitimate interests pursued by that party, except where such interest is overridden by the interests of fundamental rights and freedoms…pursuant to Article 6(1)(f) GDPR"; and
  • requirements in Appendix C, particularly ones related to outlining obligations for data registrars operating in the EU.


The ALAC appreciates the opportunity to comment on this important matter.


The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).


  1. We need technical advice on this issue.  From my non-technical perspective, therefore: When the RDAP was developed, included the functionality to provide gated access to registration data.  When ICANN adopted thee protocol   however, the functionality to provide gated access was optional - not required.  The explanation was that, at that stage - and still the case - there is no policy now in force in ICANN to require gated access to registration data.  Given that the Temporary Spec requires gated access and any final ICANN acopted policy will certainly require gated access, the functionality of gated access should be a required feature of the RDAP.

    1. You're right Holly.

      When we discussed  RDAP in the EWG, the most compelling reason it was reported favourably was the capability vested in the protocol to process multiple attributes in decision-making on access; who, what, how and how long.   That ICANN chose to endorse a less-than-ideal implementation is regrettable.  But that is not a disability of the protocol.  We should record that, along with the political decision.



    2. To be clear, the Temp Spec does not require gated access. It requires that contracted parties respond to requests, not necessarily through an automated protocol.

      The EPDP policy may need gated access if we can all agree to do so. Without lowering contracted parties liabilities if they rely on such access and are then cited for a breach of GDPR, it is unlikely, in my mind, that we will come to such an agreement.

  2. In my opinion, it collects assertive suggestions for the implementation of RDAP. Therefore, I support the comment as redacted.

  3. Some ICANN accredited registrars are already providing tiered access or gated access to the registration data (Previously WHOIS data) using RDAP