Internet Corporation for Assigned Names and Numbers

About gTLD Compliance Program

The gTLD registry and sponsorship agreements share a common basic structure, although the specific requirements may vary. The gTLD Compliance Program was developed by first compiling a full listing of all obligations enumerated in the agreements and establishing what procedures could be used to review each on a regular basis. These provisions were then divided into seventeen general Compliance Areas, so that all items corresponding to a particular contractual policy area could be dealt with as a whole.

Compliance Areas

  1. Functional Specifications

    These include protocols, zone file generation, OT&E, and grace periods. Most of this covers how a registry's systems work. To determine whether they are complying, ICANN will obtain access to the registrar area which includes these specifications, and to receive copies of all registrar announcements pertaining to changes in specifications. In the case of a sponsored TLD, the agreement prescribes minimum functional requirements which the sponsor must ensure are being met by the registry operator. It is most important that we check this area in relation to new items—a new service, or a change in protocol. Therefore, this is an area that should be triggered when something changes (new services or policy requirements).

  2. Performance Specifications

    Performance specifications set standards for availability, outages, processing times, and update frequencies. For a sponsored TLD, the agreement prescribes minimum performance requirements which the sponsor must ensure are met by the registry operator. For an unsponsored TLD, the specifications are covered in Appendix 7 and supplemented by Appendix 10, which describes the credits due to registrars in the event the registry does not meet the performance specifications. The monthly registry reports compare Service Level Agreement ("SLA") requirements with actual performance measures for the reporting month. Registries typically send out notifications to registrars about outages, updates, etc. ICANN also receives these announcements and will compare these with the registry's reported data. This area needs to be and can easily be checked on an ongoing basis.

  3. Equivalent Access to Registry Services

    This area includes the obligation of the registry to provide equivalent access to all registrars and, in the case of unsponsored TLDs, the obligation to provide regular certification to ICANN that they are doing so. Registries send ICANN certifications on an individual bi-annual schedule, and the compliance program can co-exist with their existing schedules. In the case of unsponsored TLDs, violations of equivalent access provisions can also be handled through the sanctions provisions in the agreement if this is warranted.

  4. Reserved Names

    This encompasses the Schedule of Reserved Names and the list of names which are registered or in use by the registry operator. We will check for compliance on the first area by simply checking reserved names to see if they resolve or have Whois records--a tool may be developed by the tech staff to help do this. The second area limits the number of names which may be directly registered by the registry operator (however, the registry can register additional names through registrars). The number of total names in use by the registry operator/sponsor is reported to ICANN as part of the monthly reports.

  5. Zone Files

    The registry's Zone File Agreement must take the form specified in the Registry/Sponsorship Agreement. We will check whether a registry has altered the agreement or imposed extra conditions by reviewing the registry zone file agreements, which are usually publicly available.

  6. Whois

    This is a multi-level area and the subject of an ongoing PDP. Registries are required to provide a public Whois service, containing required data elements. They must also provide access to the Whois data to ICANN and to a third-party operator in the event that a centralized Whois system is developed. Compliance questions include whether the registry is providing appropriate access, meeting update frequency requirements, and following bulk access provisions. We will continue to enforce any Whois policies which may be developed and adopted as a consensus policy as a result of the PDP. We are also working to coordinate with registries the use of compatible formats (as an example, the Whois Data Problem Report System which encompasses all registries but requires several mapping tables which must be maintained and corrected by staff).

  7. Data Escrow

    The data escrow specifications are enumerated in the Agreement. Copies of deposit submissions by registries and verifications by the data escrow agent are currently received by ICANN in order to confirm that all registries are in compliance with current data escrow requirements.

  8. Registration Restrictions

    Restricted registries have dispute policies in place to provide standards for resolving disputes over inappropriate registrations. The sponsored TLDs have an easier time with this area as they employ their own eligibility processes for registrations. Although the unsponsored restricted TLDs are not contractually obligated to ensure or check that the registrations in their TLD meet the restrictions (for example, ineligible sunrise registrations, registrations in .name that are not personal names, etc), we should review the registrar toolkit and the marketing information provided by the registry to check for possible sources of confusion in the marketplace regarding the restrictions. We will also check to make sure that the registry has the proper dispute resolution mechanisms available to registrants.

  9. Use of Registrar Data

    The agreements specify that a registry must take reasonable steps to protect the data that they get from registrars (i.e., Whois). Registries must inform registrars of any ways in which they use the information, and may not use it for any reason outside of what they have disclosed. Compliance checking in this area involves reviewing the registry communications to registrars and discussing with them what their practices are for handling of this data.

  10. Payments to ICANN

    Data on registry payment records is easily available from Finance. Warnings and notices on late payment that are currently in use will be integrated into the compliance program in coordination with finance staff.

Stay Connected

  • News Alerts:
  • Newsletter:
  • Compliance Newsletter:
  • Policy Update: