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).
Comments concerning the layout, construction and
functionality of this site
should be sent to webmaster@icann.org.
Page Updated
20-Oct-2002
©2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.
|