To the Names Council:

Recently the DNSO Transfers and Whois Task Forces have issued interim reports concerning possible revisions to registrar-transfer and Whois policies. These Task Forces are considering policy recommendations that would establish many new requirements for ICANN-accredited registrars and ICANN-designated registry operators to follow in their businesses. Several of the registrars and registry operators have expressed alarm concerning the effect that these proposed requirements would have on their operations, and have indicated that they presently oppose some of the requirements being considered.

Within the framework ICANN operates, efforts to implement policies through registrars and registry operators must take into account the agreements between those entities and ICANN. The purpose of this briefing is to describe the provisions of ICANN's agreements with registrars and registry operators to give the Names Council, its task forces, and the DNSO generally information regarding the circumstances under which registrars and registry operators must implement ICANN policies. This guidance should assist the DNSO in developing policies that can be implemented under ICANN's agreements, so that the goals the policies are intended to promote can be achieved.

Overview

As a private-sector coordination body, ICANN does not possess governmental powers. To implement the policies developed through its processes, ICANN must rely on the agreement of registrars, registry operators, and other entities involved in the operation of the systems (such as the DNS and the IP address-allocation system) that ICANN coordinates.

In theory, agreement of the implementers could be achieved on a policy-by-policy basis at the time that the policies are developed. Although this approach has been followed at times, it is vulnerable to narrowly self-interested demands by one or a few of the entities necessary for a policy's implementation. Experience shows that this mode of implementation is ordinarily impractical. To address this situation, ICANN has entered agreements with registrars and registry operators under which those entities agree in advance to implement ICANN-developed policies under contractually specified conditions.

In entering these agreements, registrars and registry operators understandably seek protections that ensure that the environment under which they operate is stable, predictable, and otherwise suitable for their business activities. Thus, ICANN's agreements give the registrars and registry operators the contractual right (through accreditation as a registrar or designation as registry operator) during an agreed period to conduct their activities, provided that stated requirements are met. ICANN can terminate accreditation of a registrar or designation of a registry operator only under circumstances prescribed in the agreements.

ICANN's agreements with registrars and registry operators set forth a variety of obligations to adhere to already-established ICANN policies, such as technical interoperability requirements, Whois, competitive access by all accredited registrars to shared registries, registrar best practices, data escrow, and posting of and adherence to privacy policies.

In addition, however, the agreements accommodate the possibility that existing policies might be revised or new policies created by obligating registrars and registry operators, under specified conditions, to adhere to newly revised or created policies. In some limited cases, registrars and registry operators have agreed in these agreements to implement specific kinds of changed requirements, mainly involving revision to technical specifications, simply upon their specification by ICANN. More generally, registrars and registry operators have agreed to adhere to new or changed policies only to the extent those policies are adopted following the agreements' "consensus policy" provisions.

In the consensus-policy provisions of ICANN's existing agreements, registrars and registry operators have agreed to implement policies developed after those agreements are signed only when:

1. The policies are on a topic that is contractually defined as being appropriate for establishment by ICANN;

2. The policies are established based on a consensus among Internet stakeholders represented in the ICANN process; and

3. The registrar or registry operator has reasonable protections in its business from the effects of having to implement the policy, such as a reasonable time to implement the policy and a reasonable opportunity to pass on any costs of implementing the policy to its customers.

In view of these contractual limitations under which ICANN operates, policy development within the ICANN process, to be effective, must take account of the practical ability to implement those policies within the contractual regimes that govern that implementation. Where a policy requires the cooperation of registrars or registry operators to achieve its purpose, as a practical matter it can actually be implemented only if it meets one of the following sets of conditions:

1. The policy is developed in a way that gathers consensus support from Internet stakeholders represented in the ICANN process, including registrars and registry operators.

2. The policy is limited to one of the narrower topics for which registrars or registry operators have expressly agreed to adhere to revised policies. (In the case of registrars, one such topic is the specification of data elements displayed in Whois.)

3. If the policy can be implemented by action of registry operators only, the affected registry operators specifically agree to implement the policy. In some cases, a policy involving both registry operators and registrars can be implemented by a change to the registry-registrar agreement that can be accomplished through the joint action of ICANN and the registry operator. See, for example, Section 6.1(a) of VeriSign's registry-registrar agreement.

4. If the policy is to be implemented by registrars, the affected registrars specifically agree to implement the policy.

5. If the policy can be phased in over a period of several years, the policy can be incorporated into provisions of ICANN's agreements with registrars and registry operators at the time their agreements come up for renewal. In the case of registrars (who have five-year agreements), the existing agreements provide that any change in policies reflected in the renewed agreement must have been adopted according to the consensus policy provisions.

The above guidance applies generally, but the details of ICANN's agreements differ somewhat for registrars and registry operators, so the exact language must be consulted to analyze a particular situation.

Relevance to the Policies Being Considered

The policies being considered in the interim reports of the Transfers and Whois Task Forces would create new obligations, or alter current obligations, of registrars and, to a lesser extent, registry operators. These new or altered obligations are listed in Appendices 1 and 2.

If the policies being considered are intended for assured implementation, and not simply to be non-binding statements of desirable conduct, the policy-development process must encourage active participation by registrars and registry operators and meaningfully address any reasoned concerns they have. This is the practical reality of a non-governmental body such as ICANN that relies on negotiated agreements rather than coercive legislation to accomplish policy goals. While unreasoned objections by some (or perhaps even all) of the registrars and registry operators should not prevent the adoption of consensus policies, and thus their implementation pursuant to the terms of ICANN's agreements, reasoned objections to a proposed policy by a substantial portion of those entities that must comply with the policy will likely make it impossible to require compliance with that policy.

Conclusion

In developing policies within the ICANN process, it is important to consider the requirements for effective implementation in a contract-based structure. In the framework within which ICANN must operate, a sound policy-development process must be designed to work toward true consensus solutions that can gain the support of the full range of stakeholders, including those who are expected to implement the policies.

Many of the policy proposals in the interim reports of the Transfers and Whois Task Forces contemplate implementation by registrars and registry operators, yet many of those entities have expressed strong opposition to them. If these proposals are intended to be adopted as ICANN policies that will be binding on registrars or registry operators, it is necessary, for the reasons outlined here, to proceed in a manner that addresses the reasoned objections and concerns of these entities.

Respectfully submitted,

Louis Touton
General Counsel

Appendix 1 – Summary of New or Revised Obligations Discussed in the Transfers Task Force Report

• Instead of being required to obtain the "express authorization from an individual who has the apparent authority to legally bind the Registered Name holder", registrars could initiate transfers based (only) on "express authorization by the Registrant or Administrative Contact of record" (Transfers Task Force Report §§ 2.4, 2.14, 3.3).
• Registrars would be obligated to "take into account" registrars' and registrants' "legal, linguistic and cultural differences" (TTF §2.9).
• Registrars would be obligated to implement transfer procedures that are "as clear and concise as possible in order to avoid confusing Registrants" (TTF §2.16).
• Registrars would be obligated to issue "AuthInfo" codes to registrants within 72 hours of a request, and subject to no more authentication than required for contact or nameserver information changes (TTF §2.18).
• Registrars would be prohibited from denying transfers or AuthInfo code release in an attempt to secure payment for services (TTF §2.19).
• Registrars would be prohibited from using "Registrar Lock" in order to secure payment from registrants (TTF §2.20).
• Gaining registrars would be required to use a "Standard Form of Authorization" for obtaining the approval of the registrant or admin contact (TTF §3.4).
• Gaining registrars would be required to produce a copy of the authorization to the losing registrar within 3 business days upon request (TTF 3.4.iii).
• Losing registrars would be limited to only seven possible reasons for denying a transfer request – fraud, UDRP action, court order, identity dispute, non-payment for current or previous registration term with domain on "Registrar Hold," express objection from the registrant or administrative contact, or failure of the gaining registrar to follow the minimum required transfer procedures (TTF §§ 3.5, 5.21).
• Losing registrars would be expressly prohibited from using the absence of a response from the registrant or administrative contact to a request to verify the intent to transfer (or any other factor not listed in §3.5) as a basis for denying a transfer request (TTF §3.6.ii).
• Losing registrars would be prohibited from preventing transfers of names that are on "Registrar Lock" status (*Note: this provision would appear to require modification of the registry software and specifications since currently all transfer requests for domains on registrar lock result in an error.) (TTF §3.6.iii).
• Losing registrars could not use any verification of intent to transfer for "marketing" to existing customers, but instead such verification must be "substantially administrative and informative in nature" and would have to provide "clear instructions for approving or denying the request for authorization and a concise declaration describing the impact" of the decision (losing registrars would not be precluded from "marketing" to existing customers through "separate communications") (TTF §§ 3.8, 3.9).
• Gaining registrars would be required to "capture" the losing registrar's Whois data prior to initiating a transfer request (TTF § 5.2).
• Gaining registrars would be required to use a "Form of Authorization" that "provide[s] the Registrant with clear instructions for approving or denying the request for authorization, the identity of the Gaining Registrar (and other parties to the transaction - e.g. resellers) and a concise statement describing the impact of the Registrant's decision(s)." (TTF §5.6).
• Gaining registrars would be required to maintain specific detailed records and logs reflecting all steps of the transfer process (TTF §5.11).
• Registry operators would be responsible (possibly for a fee) for completing reviews of individual transfer requests within 14 business days of any request by a registrar. The registry operator would be obligated to request and review all applicable documentation from both the gaining and losing registrars, and make a finding as to whether the transfer was initiated or denied appropriately (TTF §8.3).
• A new Transfer Dispute Resolution Panel would hear registrar appeals from enforcement decisions by registries or direct complaints from registrars concerning inappropriate transfer requests or denials (TTF §8.5).
• Registry operators would be obligated to "provide whatever data is needed by the Dispute Resolution Panel" (TTF §8.5.3).
• The Transfer Dispute Resolution Panel could order domains to be transferred to the sponsorship of the prevailing registrar, and could impose sanctions or penalties (to be determined) on registrars that bring complaints without merit or initiate transfers without authorization (TTF §§ 8.5.vi, 8.5.vi.3).
• A losing "defendant" in a Transfer Dispute Resolution Panel case would be obligated to refund the prevailing registrar's initial filing fee (or lose its accreditation) (TTF §8.5.vi.2).

Appendix 2 – Summary of New or Revised Obligations Discussed in the Whois Task Force Report

• Registrars would be required to use "automated mechanisms to screen out obviously incorrect contact data (e.g., ZIP code/postcode matching software [at least for North American registrants], rejecting incomplete fields in contact data, etc.)" (Whois Task Force Interim Recommendation 1.0 A.4.a).
• Registrars would be obligated to obtain documentary proof of the accuracy of "corrected" contact data supplied by registrants in response to inquiries concerning accuracy (Whois Recommendation 1.0 A.4.c).
• Registrars would be obligated "to treat a complaint about false WHOIS data as to one registration as a complaint about false WHOIS data as to all registrations that contain identical contact data, and all such registrations should be made the subject of an inquiry, corrected, or cancelled, as the case may be, en bloc." (Whois Recommendation 1.0 A.4.d).
• Registrars would be obligated to verify the accuracy of registrant contact data prior to "restoring" a name via the Redemption Grace Period that was deleted the basis of false contact data (Whois Recommendation 1.0 A.4.e).
• Registrars (and "thick" registries?) would be required to pay fines of US$250, US $500 and US $1000, and be subject to temporary suspension of rights to register new names, for successive failures to correct reported inaccuracies in their Whois data (Whois Recommendation 1.0 B).
• Registrars would be obligated to require registrants to "review and validate all Whois data upon renewal of a registration" (Whois Recommendation 1.0 C.1).
• Registrars would be obligated to "spot-check a sample of registrations in order to validate the accuracy of contact information submitted" (Whois Recommendation 1.0 C.2).
• Registrars would be obligated, "to the greatest extent feasible," to employ "semi-automated methods such as e-mail pinging, automated dialing to validate telephone numbers" in order to verify the accuracy of contact data submitted by registrants (Whois Recommendation 1.0 C.3).
• Registrars (and registries?) would be obligated to use a common Whois data output format and return in response to all queries, across all gTLDs (Whois Recommendation 2.0 C).
• Registrars would be obligated to make their Whois data available for searches across TLDs by domain name, registrant name, admin and technical contact name or handle, and primary and secondary nameservers or IP addresses (Whois Recommendation 3.0 B.1).
• Registrars would be obligated to provide bulk access to Whois data only to (accredited?) "parties who are able to articulate a legitimate" (non-marketing?) need for access to the data (Whois Recommendation 4.0 A).
• Instead of being able to charge "an annual fee, not to exceed US$10,000," registrars would only be able to charge for "actual costs of providing" bulk access to Whois data (Whois Recommendation 4.0 B).
• Registrars would be obligated (it is optional under the current RAA) to require third parties to agree to not sell or re-distribute the bulk Whois data except as part of a value-added product or service (Whois Recommendation 4.0 E).
• Registrars would be obligated (it is optional under the current RAA) to enable registrants to simply and transparently opt-out (or opt-in?) of having their data available for bulk access for marketing purposes (Whois Recommendation 4.0 F).

Page Updated 20-Oct-2002
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.