Skip to main content

Registration Data Directory Services (RDDS) Roadmap Update

As ICANN org continues to keep the community informed regarding the evolution of policy and management of registration data, new information regarding ongoing projects related to Registration Data Directory Services (RDDS) has been published. Updates to this RDDS roadmap [PDF, 5.6 MB], published semiannually, show RDDS activities in advance of Board consideration, implementation following Board action, and implementation by contracted parties.

Some of the updates detailed in the RDDS roadmap include:

  • The Expedited Policy Development Process (EPDP) Team began its Phase 2 work in May 2019 focusing on the development of a System for Standardized Access/Disclosure to Non-Public gTLD registration data (SSAD), issues noted in the Annex to the Temporary Specification for gTLD Registration Data ("Important Issues for Further Community Action"), and outstanding issues deferred from Phase 1, e.g., legal vs. natural persons, redaction of city field, etc. The EPDP Team considered various models that are based on several high-level principles and concepts where ICANN would act as a central gateway for receiving and routing requests for non-public gTLD registration data. Additionally, the EPDP team is also contemplating the structure and architectural issues of SSAD to reach an agreement on how SSAD should function.
  • The EPDP team published its Phase 2 Initial Report [PDF, 1.3 MB] for Public Comment on 7 February 2020.
  • On 25 October 2019, ICANN org published "Exploring a Unified Access Model for gTLD Registration Data [PDF, 557 KB]" which outlines a proposed Unified Access Model based on the Technical Study Group's technical model [PDF, 837 KB]. The model described in the "Exploring a Unified Access Model" paper would provide a centralized system for access to non-public registration data and would be operated by ICANN org to relay authorized third-party requests for access that meet relevant policy requirements to the contracted parties. ICANN org sent this paper [PDF, 223 KB] to the European Data Protection Board (EDPB) to receive further guidance regarding the model's feasibility and whether such a model would be compliant within the framework of the European Union's General Data Protection Regulation (GDPR). In December 2019, the Belgian Data Protection Authority (DPA) sent ICANN org a non-binding letter [PDF, 112 KB] in response to the paper. The letter encouraged ICANN to continue its efforts to design a comprehensive system for access control that takes into account the requirements of security, data minimization, and accountability, but did not provide any definitive opinions regarding the questions that ICANN org included in the paper. The Belgian DPA indicated its willingness to further discuss this effort and has invited ICANN org to meet with them.
  • The Registration Directory Service (RDS-WHOIS2) Review Team delivered its Final Report [PDF, 3.9 MB] on 3 September 2019. The report assessed the extent to which prior Registration Directory Service Review recommendations have been implemented and if implementation resulted in its intended effects. The review team also assessed the effectiveness of the then-current gTLD Registration Directory Service and whether its implementation meets the legitimate needs of law enforcement, promotes consumer trust, and safeguards registrant data. The RDS-WHOIS2 Final Report was posted for Public Comment to inform Board action on the RDS-WHOIS2's 22 Final Recommendations. ICANN Bylaws call for the ICANN Board to take action on the RDS-WHOIS2 Final Report within six months of receipt, i.e. by 3 March 2020. For any recommendation the Board may decide to not accept, the Bylaws require provision of a rationale.
  • Effective on 20 May 2019, ICANN org implemented the Interim Registration Data Policy for gTLDs (Interim Policy) pursuant to the Board of Directors' 15 May 2019 adoption of recommendations contained in the EPDP Team's Final Report [PDF, 2.7 MB] developed in the Generic Names Supporting Organization (GNSO). As the Temporary Specification for gTLD Registration Data expired on 20 May 2019, the Interim Policy maintains requirements from the Temporary Specification for gTLD Registration Data, which detailed how gTLD registry operators and ICANN-accredited registrars must handle gTLD registration data as a result of privacy legislation. This Interim Policy implements one out of a total of 29 recommendations made by the EPDP Team in Phase 1.

The RDDS roadmap updates [PDF, 5.6 MB] are part of ICANN org's efforts to provide the community with visibility into all RDDS-related activities. For more details on these actions, please check out the Knowledge Center on our dedicated portal at

If you have any further questions, please reach out to me at


    Rahul Sharma  21:40 UTC on 03 March 2020

    Is it possible to prepare a roadmap for small oranizations like WSNE Consulting.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."