Skip to main content
Resources

FAQ for implementing the Temporary Specification for gTLD Registration Data

Updated 6 July 2018

This page contains answers to many of the most frequently asked questions for implementing the Temporary Specification for gTLD Registration Data. It will be updated as the answers change, or as new questions become frequent.

If you have a question not listed below, you may send your question via email with "Temporary Specification" in the Subject line to globalsupport@icann.org. If you require further information or clarification about an existing FAQ included here, please include the question and answer within the body of your email.

Applicability

  • When will ICANN begin to enforce the requirements in the Temporary Specification for Registries and Registrars?

    ICANN org's Contractual Compliance team is enforcing the Temporary Specification as of its effective date, 25 May 2018.

  • If I am a registrar not based in the European Economic Area (EEA) who only has registrations from non-EEA countries, do I need to do anything to implement the Temporary Specification?

    Yes. All contracted parties are advised to review the Temporary Specification carefully, as many of the requirements apply even if the registrar is not in the EU and has no registrations from the European Economic Area. See for reference the slides from ICANN's 6 June 2018 webinar [PDF, 213 KB] which highlight items that are required of all registrars, regardless of their or the registrant's geographic location.

  • If I am a registry operator not based in the European Economic Area (EEA) who only has registrars and registrations from non-EEA countries, do I need to do anything to implement the Temporary Specification?

    Yes. All contracted parties are advised to review the Temporary Specification carefully, as many of the requirements apply even if the registrar is not in the EU and has no registrations from the European Economic Area. See for reference the slides from ICANN's 6 June 2018 webinar [PDF, 213 KB], which highlight items that are required of all registry operators, regardless of their or the registrant's geographic location.

  • As a registrar, do I need to apply the redacted WHOIS/RDDS output specified in Appendix A to all registrations or only those from the EEA?

    Registries and registrars must apply the requirements of Appendix A to their RDDS output if any of the three conditions in section 2.1 are satisfied. Registries and registrars MAY apply the requirements across all registrations where it is commercially reasonable to do so or it is not technically feasible to limit the application of the requirements in section 2.1. If the contracted party implements section 2 of Appendix A because it is either mandated or chooses to do so, it then must implement section 4 of Appendix A.

  • How does the Temporary Specification apply to a registration that is protected by a privacy or proxy service?

    If a registration is protected by a privacy or proxy service, the registrar is required to display the privacy and/or proxy registration information in the public WHOIS. This answer is the same, regardless of whether the registrar is required to redact information in the public WHOIS pursuant to Appendix A, Section 2.1, of the Temporary Specification. The Temporary Specification requires, at Section 2.6 of Appendix A, that in the case of a domain name registration where a privacy or proxy service is used, the registrar must return the non-redacted privacy/proxy registration data in response to any query, including the existing privacy/proxy pseudonymized email.

Registration Data Collection & Display

  • As a registrar who will be redacting the technical and administrative contact data fields, can I stop collecting these data points?

    No, the Temporary Specification for gTLD Registration Data does not modify the requirements for collection of registration data by a registrar as prescribed in the relevant Registrar Accreditation Agreement (RAA).

  • What are the requirements for the anonymized email if we elect to use a web form?

    The web form is intended to relay communications to the relevant contacts. The only requirement in the Temporary Specification is that the communication be forwarded to the relevant contact. To allow for flexibility for implementation, the Temporary Specification does not include additional requirements, however, registrars must continue to adhere to the relevant requirements in the RAA about dealings with the registered name holder, including for example maintaining copies of correspondence with the registered name holder (see RAA Section 3.4.2).

Consent to Publish Registration Data

  • What should a registrar do for those registrants who want their contact data shown in the public WHOIS?

    Section 7.2.1 of the Temporary Specification states that "As soon as commercially reasonable, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to publish the additional contact information outlined in section 2.3 of Appendix A for the Registered Name Holder."

  • Can a registry publish the email addresses in public RDDS for the Registrant, Administrative or Technical contacts if the contact has provided consent to publish?

    If the registry is informed that the registered name holder has provided consent to publish any registration data then the registry MAY publish the data in the public RDDS.

  • How should a registrar inform the registry that the registered name holder has provided consent to publish their contact information in the public RDDS?

    The Temporary Specification does not prescribe the mechanism for registrars to relay registrant consent to the registry. The registries and registrars are expected to determine the appropriate mechanisms amongst themselves.

Inter-Registrar Transfers

  • As a gaining registrar, can I ignore the gaining Form of Authorization (FOA) for all transfers, as the WHOIS information at the losing registrar may or may not be available?

    No. Appendix G of the Temporary Specification only applies if the then-current registration data is not available in the public WHOIS/RDDS at the time of the transfer request. If the registration data is available, the Transfer Policy applies.

Data Escrow

  • When will ICANN provide approved data processing language for data escrow agreements as referenced in Appendix B of the Temp Spec?

    ICANN org is working with the approved data escrow providers to define the appropriate data processing language. We will notify the contracted parties once this language becomes available. Contracted parties are required to continue to escrow data in accordance with the existing contractual requirements, which are not modified by the Temporary Specification for gTLD Registration Data.

Registry-Registrar Agreements

  • Where can I find the approved data processing language for Registry-Registrar Agreements (RRAs) as referenced in section 6.3.2 of the Temporary Specification?

    ICANN has published model terms for RRA amendments that satisfy the requirements of sections 6.3.1 and 6.3.2. These are available in the Additional Resources section on the Temporary Specification for gTLD Registration Data page. Instructions for how to apply these changes and notify ICANN are available here.

  • How did ICANN develop the approved data processing language for the Registry-Registrar Agreements (as referenced in section 6.3.2)?

    ICANN worked in collaboration with the gTLD Registries Stakeholder Group and the Registrars Stakeholder Group to develop the model terms for RRA amendments.

Bulk Registration Data Access (BRDA)

  • Does the Temporary Specification change the requirements for BRDA?

    Most of ICANN's registry agreements require the registry operator to provide to ICANN bulk access to thin registration data for specific purposes, but allows the registry operator the option to make the thick bulk registration data file available for access by ICANN. The Temporary Specification for gTLD Registration Data modified the requirements for Bulk Registration Data Access via Appendix F. Registry operators must now provide thin registration data only, as submission of thick registration data is no longer permitted. Please review Appendix F and update your systems accordingly as soon as possible.

Registration Data Access Protocol (RDAP)

  • When do I need to have RDAP in place?

    The RDAP Pilot working group is currently developing an operational profile(s) for RDAP. ICANN org expects to have a final operational profile available by the end of July 2018. Once the profile is available, ICANN org intends to notify all registries and registrars to implement RDAP within 135 days, per the existing requirements in their agreements with ICANN. This means contracted parties should plan to have RDAP in production by December 2018. Contracted parties are strongly encouraged to begin their preparations now. See the RDAP page for more information including how to join the RDAP pilot mailing list, and the RDAP pilot program.

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""icann.org"" is not an IDN."