|Adopted: Updated 2013|
|Summary: agreement between a registry and ICANN|
|Addresses: general behavior and expectations of registry performance,|
including Phishing, Spam, Botnet Attacks, Wildcarding, Malware, Piracy
|Also addressed by U.S. Legislation: N|
|Related to: RAA|
The Registry Agreement or RA is a document signed by ICANN and a registry in which the registry agrees to abide by certain rules and procedures defined by ICANN. The RA "sets forth the rights, duties, liabilities and obligations of the applicant as a Registry Operator." The new gTLD program has lead to the creation of a revised RA in 2013, which all applicants were required to sign. The agreement itself contains 7 articles, an exhibit A section for approved services, and 12 specifications, although the community specification (12) does not apply to all applicants.
- Article 1: generally addresses the delegation and operational aspects of being a registry operator.
- Article 2: outlines the services that registry operators must provide, such as data escrow, pricing, and the storage and use of registrants' personal data.
- Article 3: lists the covenants of ICANN.
- Article 4: outlines the length of the registry agreement (10 years) and the termination of the contract if initiated by ICANN or the registry.
- Article 5: addresses dispute resolution procedures, mediation, arbitration, and liability.
- Article 6: deals with fees.
- Article 7: is described as "miscellaneous" and looks at topics such as indemnification, subcontracting, amendments, and confidentiality among other topics.
- Specification 1: states that the registry will abide by any consensus or temporary policy created by ICANN even after the RA is signed.
- Specification 2: addresses data escrow practices, including the legal and technical aspects.
- Specification 3: outlines the proper format of the monthly reports that must be submitted to ICANN.
- Specification 4: states the "registration data publication services" requirements, such as Who is data formatting.
- Specification 5: discusses reserved names.
- Specification 6: addresses registry operations and continuity issues, including the prohibition of wildcarding and the emergency transfer of services in the case of an "extraordinary event."
- Specification 7: this section talks about the minimum amount of required RPMs, including the URS and the trademark clearinghouse.
- Specificaiton 8: addresses the "continued operations instrument" provided by the registry to prove that it has the financial ability to support itself.
- Specification 9: outlines the registry operators code of conduct.
- Specification 10: defines important terms.
- Specification 11: is discussed in depth below.
- Specification 12: applies to registries that have community registration polices and rules.
This part of the RA, also called the Public Interest Commitments, explicitly addresses certain Internet behaviors and outlines some additional registry operator responsibilities:
- It specifies that registries must require their registrars to include policies that prohibit registrants from activities that have caused problems in the past, such as spreading malware, creating botnets, phishing, spamming, piracy, trademark infringement, fraud, and illegal activities.
- Additionally, registries are required to "periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats" and to keep security files on threats and the remedial actions taken by the registries.
- It also states that registry operators must use ICANN accredited registrars to sell their domain names.
- It states that registries must "operate the TLD in a transparent manner consistent with general principles of openness and non‐discrimination by establishing, publishing and adhering to clear registration policies."
Points of Interest
- If a registry operator does not comply with the RA, then they will receive a notice from ICANN and have 30 days to remedy the issue. If the registry does not fix the breach of contract, ICANN can terminate the RA.
- Registries may be required to violate certain sections of the RA in order to prevent imminent security threats or to preserve the registry from failure. If such drastic action is required, the registry should submit an Expedited Registry Security Request (ERSR), which ICANN will respond to within 3 days. In emergency situations, ERSRs may be submitted and granted retroactively.
- Submit an ERSR
- View example RAs
- Read the 2013 RA on ICANN's Contracting and the Registry Agreement Page
- Learn more about the ERSR
- http://newgtlds.icann.org/en/applicants/agb/base-agreement-contracting Internet Corporation for Assigned Names and Numbers (ICANN)
- https://blog.icann.org/2013/07/ngpc-approves-new-ra/ by Cyrus Namazi (July 3, 2013), ICANN Blog
- http://newgtlds.icann.org/en/applicants/agb/base-agreement-contracting PDF titled View the Updated Registry Agreement, Internet Corporation for Assigned Names and Numbers (ICANN)
- https://www.icann.org/resources/pages/ersr-2012-02-25-en Internet Corporation for Assigned Names and Numbers (ICANN)