ICANN | Consultation on Registrar Accreditation Agreement Amendments: Synthesis of Public Comments Received

Quick Links:

Tell us how we're doing: Please answer a few questions about your experience to help us improve ICANN.org.

Consultation on Registrar Accreditation Agreement Amendments: Synthesis of Public Comments Received

The ICANN Board of Directors adopted a resolution at the San Juan meeting that directed staff "to solicit and consider the input of the Internet community, including the At-Large community and the GNSO constituencies, regarding proposed changes to the RAA, registrar accreditation process, and related policies” and to "engage with the Registrars Constituency in order to arrive at, and post for public comment, a set of proposed amendments or alternative version to the RAA, that is intended to address to the extent feasible the concerns raised by the Internet community.”

To this end, staff opened a public comment period on the ICANN website to solicit initial public input (http://www.icann.org/topics/raa/) with the understanding that such input would be synthesized for discussion with the Registrar Constituency. This document is intended to provide such a synthesis. This summary will take into consideration comments received during the initial period from 30 July through 10 September 2007.

A total of 53 public comments/recommendations were received during the initial period, with three individuals contributing the majority of comments (copies of all submissions can be found at http://forum.icann.org/lists/raa-consultation/). The Intellectual Property Constituency submitted a redlined version of the RAA to reflect changes it recommended. A subsequent submission from the At-Large Advisory Committee (ALAC) was also received and its recommendations are also included in this summary.

While the recommendations suggest a sincere interest in change, many of the comments fell outside of the scope of RAA amendments. Because the Board directed staff to solicit comments on "proposed changes to the RAA, registrar accreditation process, and related policies”, some of the comments cover qualifications and policy issues that would not be directly addressed through RAA amendments. Some comments were more general in nature or fell outside the scope of the ICANN-registrar relationship in other ways. All comments are listed, but this summary attempts to isolate those items that will facilitate the discussion on RAA amendments at this time. While staff wishes to provide for the broad range of input received, some form of classification was deemed necessary to focus the discussion for the purpose of amending the RAA. It is possible that some of the suggestions listed below could fall into more than one category — and views may differ on how the suggestions should be classified, so attention should be given to the content of each recommendation, not only its classification.

For those recommendations that may fall outside the scope of RAA amendments, ICANN wishes to work with interested community members in order to promote constructive ideas. ICANN will explore different fora for the subsequent discussion.

All comments have been numbered to provide ease of reference.

The following suggestions are in line with the initial amendment proposals and have been taken into consideration in drafting language that is being negotiated between the registrars and ICANN.
1. ICANN should govern terms for sales of registrars to new owners
2. Require groups of registrars to be responsible for actions of individual registrars
3. Require Data Escrow of privacy services data
4. Enhance requirements of registrars for behavior of resellers
5. Require operator skills training
6. Training recommendation for skills testing to help thwart spam
7. Registrar is responsible for behavior of resellers, including any penalties
8. Require resellers to indicate the name of the registrar on its website
9. Provide for termination of a registrar for actions of its affiliates
10. Provide for graduated sanctions
11. Add a change of control provision that permits ICANN to audit for compliance following a change of control
12. Add a control of affiliates provision that extends the agreement to affiliates
13. The revised RAA should contain a range of incentives and remedies short of revocation, such as public admonishment, fines, and temporary suspension of new registration privileges.
14. ICANN should require that any registrar that sells through resellers have binding agreements with their resellers that pass through registrar’s duties to registrants.
15. The RAA should include the proposed amendment that requires that when registrars are aware that a registration is performed by a proxy, the escrowed registrant data must include the information for the actual registrant, unless the actual registrant opts out.

The following suggestions may be feasible to include as revisions to the RAA and will be included in discussions between the registrars and ICANN.
1. RAA should allow for arbitration of damages instead of sanctions, like registry agreements
2. The leasing of an accreditation should be addressed by the RAA (without necessarily impacting traditional reseller arrangements)
3. Expand the data escrow terms to allow use of the data to resolve disputes between ICANN and the registrar ("The escrow shall further provide that ICANN may use data held in escrow to protect registrant rights in the event of Registrar default of the terms of this Agreement and otherwise to confirm performance with the terms of this agreement. ICANN shall not disclose any information maintained in escrow to anyone other than the Registered Name Holder, except in connection with any dispute between ICANN and the Registrar concerning the Parties’ performance of their obligations under this Agreement.")
4. Add a compliance audit provision ("ICANN may at its discretion and for reasonable cause at any time audit a Registrar or any Affiliate of Registrar to determine compliance with this Agreement or with representations made in the Registrar Accreditation Application.”)
5. Add a clause in the RAA so to require registrars to clearly state the name under which they are accredited by ICANN and the number of their accreditation contract, at the time of registration and on the invoices / receipts related to the registration.

Suggestions were submitted concerning Accreditation Requirements, which should be considered separately from the RAA amendment discussions. These will be pursued as part of a larger discussion concerning the qualification requirements to be an ICANN accredited registrar.
1. Devise new criteria in accreditation process to eliminate applicants that exist only as paper entities
2. Use economic studies to determine if changes in accreditation requirements could be instituted to remove barriers to entry by applicants in the developing world

This group of recommendations includes issues that are currently being addressed in other ICANN fora or are covered by an existing policy, proposal, or items that will be considered as enhancements to existing practices and procedures, but that do not require RAA amendments.
1. Registrars should provide challenge mechanism to correct Whois identity theft (Legal and Policy options already exist)
2. Curtail domain tasting - two comments (Under consideration by the GNSO)
3. Transfer of domain names between registrars should happen "seamlessly” within 24 hours (Inter-Registrar Transfer Policy exists to govern transfers; Transfer Policy is under review by GNSO)
4. Only actual registrant information should be displayed in Whois - not privacy services (Under consideration in the present Whois policy discussion)
5. Registrars and registries should be prohibited from selling Whois check (name availability lookup) data (SSAC is conducting a review of this possible practice)
6. Registrars should be sanctioned if they don’t release Auth-Info codes in a timely manner; registrants should be permitted to acquire Auth-Info codes directly from registry; registries may need to be made "thick” (Policy exists covering the provision of Auth-Info codes)
7. Mandate an opt-out provision to let registrants keep their information out of bulk access data (Under consideration in the present Whois policy discussion; also dealt with by Registrar Constituency RAA amendment proposal)
8. Impose a means for contacting underlying registrant when privacy/proxy service is used (Under consideration in the present Whois policy discussion)
9. Adopt a registrar Code of Conduct (Provision already exists in RAA; requires consensus of registrars to adopt a Code of Conduct)
10. ICANN should post registrar violations by name (ICANN’s Compliance escalation procedures contain provisions for publication of violations under certain circumstance)
11. Require registrars to include a link for reporting bad Whois in the Whois lookup record that links to ICANN’s WDPRS
12. Convene an accreditation workshop (Such a workshop has been scheduled for the ICANN meeting in LA)
13. Add a provision that spells out terms under which a registrar can substitute contact details in the Whois record for the actual Registered Name Holder and that facilitates timely resolution of problems involving those names (Under consideration in the present Whois policy discussion)
14. Require registrar to provide contact information for licensed domain names (Under consideration in the present Whois policy discussion)
15. Require registrar to provide "accurate” and "valid” contact details that are regularly checked by the registrar and requires registrar to respond to third party inquiries concerning names under management within 24 hours (Under consideration in the present Whois policy discussion)
16. ICANN should define internal procedures to monitor registrar compliance, accept public reports of problems and non-compliance, and engage in corrective actions in a timely fashion. (ICANN’s Compliance unit has such procedures)
17. ICANN should establish an online method specifically to accept complaints about registrar behavior; while ICANN cannot generally solve individual problems, consumers can still receive pointers to useful information in various languages, and to appropriate consumer protection agencies and organizations. This mechanism would allow ICANN to extract aggregated information to recognize developing problems with registrars.(Online complaint filing exists, while the Translation Policy is under development to address a variety of translation needs)
18. ICANN should continue to conduct regular assessments of the compliance of each registrar, either directly or through third parties, using a standardized checklist that verifies the compulsory behaviors (e.g. compliance with applicable ICANN policies), the average levels of service (e.g. technical performance, average rate and speed of response to customer inquiries), and a set of performance indicators that could warn about possible problems (e.g. degradation over time in new registration and transfer-away rates). Compliance should be verified at least once a year. (ICANN’s Compliance unit has an annual audit schedule for registrars)
19. Using automated electronic means (e.g. search engines), ICANN should identify and combat abuses of the "ICANN accredited” logo by unaccredited parties. (ICANN regularly monitors uses and aggressively challenges abuses of its logos)
20. Develop a clear and uniform document describing the roles, requirements and use of the different contacts, that could be used as a reference document by registrants and by third parties registering domain names on their behalf, also in case of controversies between them. (Under consideration in the present Whois policy discussion)
21. We ask that ICANN provides official translations of the transfer forms and rules into major languages; the registrant should be able to perform the entire procedure in his/her native language, if it is one of the supported ones. (ICANN’s Translation Policy is under development to address a variety of translation needs)
22. ICANN should establish procedures to follow when a registrar has failed, to select one or more other registrars to which to transfer the registrants. (Procedures for handling of registered names managed by failed registrars are under discussion)
23. ICANN should establish procedures to verify that registrars are properly escrowing data, by spot checks and other means. (ICANN’s registrar data escrow program has such provisions)
24. Add the right to inspect registrars in order to police use of the ICANN name and reputation (Inspection rights already exist in the RAA)

ICANN is structured so that major policy decisions with broad impact are arrived at through a bottom-up consensus process. The following suggestions are considered by staff either to be under discussion in the context of a Consensus Policy already or, otherwise because of their nature, could/should be handled through the Consensus Policy process. Adopted Consensus Policies are enforced through the RAA.
1. ICANN should establish or provide a dispute resolution mechanism for unauthorized changes of registrant
2. ICANN should require registrars to verify registrant identity
3. Registrars should be prohibited from registering and otherwise acquiring domain names and should be divested of domain name registrations
4. ICANN should create a registrar shared database of "invalid” domain names
5. Require adherence to Consensus Policy - eliminate post expiration loopholes (Staff note: Consensus Policy compliance enforcement already exists, further limitations to existing policy would require the adoption of additional Consensus Policies)
6. ICANN should assure that a centralized Whois be established that is searchable to benefit UDRP complainants
7. ICANN should reconvene the Technical Steering Committee to introduce competition into the RGP
8. Require verification by mail of a registrant’s address prior to activating domain name
9. Establish registrar action deadlines for dealing with registrant non-compliance
10. Enable registrars to do mass deletions of names registered by proven serial spammers and block attempts at future registrations
11. Contact data should be verified at the time of collection.
12. While the obligations of registrars for what regards transfers are implicit in their obligations to abide by ICANN consensus policies, we think that, given the extreme importance of this policy, it would be useful to add a clear reminder in the RAA, under the form of a clause saying something like "The registrar recognizes the right of the registrants to transfer their domain names to other registrars, according to the policies established by ICANN, and commits to make the process of transferring domain names as simple and quick as possible, and not to unreasonably stifle this opportunity in any way.”
13. We ask that the GNSO Transfer Policy include specific requirements to enable transfer of domain names. Registrants should be able to process a transfer entirely through the services of the gaining registrar and/or the registry, without the need for action by the losing one, including obtaining Auth-Info codes and the like when required.
14. We ask that the GNSO Transfer Policy forbid losing registrars to require an extra fee or paperwork to transfer their domain names. Since the entire transfer process can be automated, its operational cost is so low to be covered by the registration fee, and there is no cost justification for extra fees.

The remaining suggestions may not be suitable as amendments to the RAA either because they cannot be feasibly implemented as RAA provisions, because the issue is best addressed through the freedom and choice available to registrants as they select a registrar, or because they are beyond ICANN’s mission and scope. To the extent feasible registrars or other parties may be in a position to implement some of these recommendations.
1. ICANN should limit disclaimers in registration agreements and require registrars to accept some legal liability
2. ICANN should require standardized Acceptable Use Policy in registration agreements to address criminal fraud
3. Registrars should be required to offer a 30 day auto-renew grace period after expiration of a registration
4. ICANN should take steps to ensure impartial, equal, and fair access by preventing special access to domain speculators
5. Revoke domain names that are sold for more than "face value”
6. Restrict the number of domain names that can be registered by a single entity in a specified period of time
7. ICANN should disallow domain name parking
8. Expired domain names should be available to original registrant for an extended period of time
9. Unauthorized registrar switching ("domain name slamming”) should be prevented
10. Actual registrant should control name, not a third party registration service
11. ICANN should publicly display all registrar officers and directors, particularly when a registrar’s accreditation is terminated
12. ICANN should include penalties from registrars to registrants for poor service as an enforcement tool
13. ICANN should create penalties for registrars to discourage typosquatting
14. Create common RAA and Whois requirements across all TLDs (including ccTLDs)
15. Registrars should be required to offer DNSSEC
16. ICANN should require registries to notify ICANN when accounts become under-funded; ICANN must issue Public Alerts when this occurs
17. Terms of Service Agreements should not be used to circumvent Consensus Policies
18. By Code of Conduct or RAA, registrars should heed security-driven recommendations
19. ICANN should consider transferring the burden of enforcing the RAA from itself to domain name registrants by making domain name registrants third-party beneficiaries of the RAA.
20. Add a clause in the RAA to require registrars to show a standardized description of registrant rights, to be provided by ICANN in different languages, as an appendix to the contract at the time of registration, and also to make it available in the registrant’s domain management interface whenever available. Such obligation should also be passed onto resellers.
21. We ask ICANN staff to prepare a summary of the current practices, fees and burdens imposed on registrants by a significant sample of registrars. (The ALAC is ready to ask for an Issues Report if necessary).
22. ICANN should appoint a separate entity, targeted with the task of conducting compliance assessments similar to those delineated in Compliance above. A suitably independent entity could do the assessments both for the purpose of ICANN’s compliance verification activity, and for the purpose of releasing ratings. Consumers Union, an ALS in the United States with extensive experience in product ratings, has expressed willingness to assist.
23. The delegated entity should continue to conduct assessments at least once a year, and should produce a graded rating published on ICANN’s website and on a specific page aimed at final consumers, and disseminated over the Internet through outreach and information campaigns.
24. Registrars obtaining top grade evaluations should be allowed to display a specific mark on their website.
25. Registrars obtaining a very low grade should be immediately subject to specific corrective measures by ICANN, and, if appropriate, to sanctions according to the compliance provisions of the RAA.
26. ICANN should have an inexpensive program to accredit resellers.
27. ICANN should consider including resellers in the compliance and rating evaluations described above.
28. ICANN should define criteria to determine when a registrar has failed, such as failure to process transfers and registrations in a timely fashion. Voluntary closure of a registrar should be treated as failure unless the closing registrar has taken action to transfer all of its registrants to other registrars.
29. ICANN should use the results from the compliance and rating assessments, as well as any other available information, to monitor which registrars appear subject to possible failure in the near future.