Here is a list of deletions we have made from the current unsponsored agreement. If
ICANN wants to put any of these items back in, they should be obligated to explain why
they are necessary.
(We are focusing on the unsponsored agreement because it is the model for the current
sponsored agreement -- and we think the entire concept of "sponsored" TLDs has
posed real problems for ICANN's legitimacy and makes little sense in reality. See "Old
Delusions and New TLDs," posted on ICANNwatch on November 13, 2002. ICANN
should be opening up TLDs that can find and create their own markets, and use their
revenues however they want -- by the way, the idea set forth in the RFP that the new
applicants must use all of their revenue for the benefit of their community underscores
the silliness of this sponsored/unsponsored distinction and should be dropped as a
requirement. Is buying phone service a "benefit to the community"?)Items removed from the main agreement
for model before deletions)
Items removed from appendices
- Removed unnecessary definitions.
- Removed terms of license from ICANN to use the ICANN logo -- has led to
unnecessary contractual amendments when registries change the logo slightly to fit
- Removed functional and performance specifications; registries should be allowed to
operate registry in whatever manner they feel appropriate, subject to consensus
policies mandating particular elements of the registry.
- Retained concept of ICANN Accredited Registrars; added concept of registry sales
through parties who have agreed to abide by consensus policies under agreements that
designate ICANN as a third-party beneficiary.
- Removed startup period language, which added complications without benefits.
- Removed ICANN as beneficiary of escrow; registry should be able to designate
party to run registry if it fails to abide by this Agreement.
- Removed existing registry fee provision because unnecessarily complicated;
substituted agreement to contribute to ICANN on an equitable scale.
- Revised scope of consensus policies to match revisions to the rest of the
- Removed price cap for registry services; substituted agreement not to charge more
for renewals than for initial registrations.
- Removed whois and bulk access obligations; these issues should and will be the
subject of consensus policies.
- Removed expiration provisions; substituted automatic renewal if not in breach.
(To see the model appendices, go here for an unsponsored model, and here
for a sponsored model):A: Format and Technical Requirements for Requests to Change TLD Nameservers
This process could change from time to time, so there is no need to lock it down in the
contract. The main agreement includes a duty to notify (and to process the change).
The parties can easily agree on format and means from time to time. Refusal to accept
a reasonable means for notice would in any event be a violation of the implied promise
of good faith and fair dealing.
B: Format and Technical Requirements for Requests to Change TLD Contact
Same reasoning as for Appendix A above.
C: Functional Specifications
Each registry operates differently. Each must change continuously to keep up with
technology and meet market demand. The only requirement ICANN should impose is
that the registry run in compliance with key IETF specifications. All registries have
incentives to comply with those, in any event, to make their registry succeed in the
market. Registrars and registrants will adopt a registry based in part on whether it
operates soundly. If it fails, the contract can be terminated. Registries have very different scales, so there is no one specification that all could be
required to follow. If the specifications are different, what gets required is clearly a
function of the bargaining leverage of staff at the time of renewal.
This entire subject should be the same as whatever is required objectively for new
TLDs -- and that is really a selection criteria rather than an appropriate subject for
ongoing "enforcement" and contractual obligation. Each registry has the normal
business incentive to operate as well as possible. The Board should not try to run these
businesses. Escrow protects in event of failure.
D: Performance Specifications
Same response as for Appendix C above. This should be covered by objective
"minimum requirements" for any registry and need not be part of the contract because
ICANN will not in fact have (nor should have) resources to police this over time.
E: Service-Level Agreement
Some registries can offer this to entice loyalty from registrars. But why is it needed? It
differs for each registry -- so only reflects relative bargaining leverage. Changes in
technology will make it obsolete. If registrars want promises before they will promote a
registry, they can negotiate for them separately. Will be out of sync with the new
structure if non-registrar channels can be used (subject to compliance with consensus
policies).F: Registry-Registrar Agreement
Why should ICANN tell registries what they must offer registrars, or tell registrars what
they must accept? ICANN "accredits" registrars and may insist that they follow
consensus policies. But it is not itself in the business of being a registry and shouldn't
tell other registries how to behave. The original competition concerns that gave rise to
this agreement are gone (and will further disappear as new TLDs are opened more
freely). This was just the way for DOC and ICANN staff to impose their own view of the
business model. There is no equivalent for sTLDs and ccTLDs. G: Fees for Registry Services
The market should regulate these fees. The only market failure would occur if a registry
exploited the lock-in effect, where a registrant invests heavily in a name and then needs
to renew. Setting renewal fees at no higher than initial registrations protects against
that. There are serious antitrust questions with any other "regulation" of price by
ICANN, a private entity that includes competitors.
H: Equivalent Access Certification
Registries should be able to be their own and only registrars if they want to be, or
should be free to use multiple registrars if that is helpful to them. If registrars want to
provide the service of creating a distribution channel, they will do so and registries will
have incentives to do business fairly with those that do. The original problem that gave
rise to the creation of registrars was the risk of NSI favoring its own registry to the
exclusion of others. Thus, if this requirement is retained, it should be imposed only on
.com and .net, and should be voluntary for all other registries under contract with
I: Registry Code of Conduct
Raises substantial antitrust issues. No real reason for this. Many registries operate
differently. There is no principled reason to require "neutrality" as between registrars.
Different registries were able to draft their own codes of conduct during negotiations
with Louis Touton. Most are meaningless. If meaningful, they need to be able to
J: Transition Plan
Complex and not relevant over the long term. Why lock this into the contract?K: Names Reserved from Registration
This would keep anyone from reserving museum.aero, for example, and makes no
sense over the long term There is no basis for these lists in any consensus or sound
technical policy. If there is an IETF RFC that requires this, we can include lists in
minimum qualifications for new TLDs. But semantic shaping of new TLDs has been
soundly rejected by the GNSO and the rest of the community.
N: TLD Zone-File Access Agreement
Every registry already makes zone files widely available. They have to do this to make
the TLD work. But registries should not be obligated to make zone files available to
anyone who asks. No reason why ICANN must get these from particular source or in
Whois should be a matter of consensus policy and/or local laws. The community
clearly doesn't like the status quo that has been built into these clauses by staff.
P: Whois Bulk Data Provisioning
same as above
Q: Whois Data Specification--ICANN
same as above. The contract language has drifted away from actual technical practice
and is not enforced -- and registries do things different ways (fat and thin etc.)
R: Data Escrow Specification
Core contract requires escrow agreement -- no need for separate appendix.
S: Data Escrow Agreement
No need for ICANN to be recipient of data. Core contract does call for an agreement --
but it is a separate document, no need to be an appendix. Wasn't actually ready in
most cases anyway, so this is just a placeholder.
T: Monthly Registry Reports
While it is important to track the performance of the registries, the current reporting
requirements are widely viewed as overly burdensome. The level of reporting appears
to be more appropriate for a regulatory agency, but less so for a consensus policy
forum, and must add significantly to ICANN staff's burden. Reporting should be boiled
down to some necessary level.
U: Proof-of-Concept Reports
Same as above -- and many subjective elements.
V: Initial Consensus Policies
This is the new appendix A -- would list all four.
W: Additional Covenants
These were ridiculous and were aimed at VeriSign. For example, the current
"sponsored" TLDs have been asked to promise never to merge into any regisy operator
who had more than 10 million names under management -- a condition that fit only
VeriSign as a potential partner. X: Registry Operator's Domain Names
Risk here was warehousing -- contract allows consensus policy to prohibit that. It is silly
for ICANN to get into particular strings. Y: Sanctions Program
This was extorted by force -- sets up staff as police and prosecutor and judge and jury.
ICANN should instead establish an independent review panel. The idea that lesser
penalties will make it easier to enforce appears persuasive, until you think about large
staff trying to make their quota of parking tickets. Market will police bad business
practices. Failure to abide by consensus policies is more serious and should lead to
serious disputes -- that's why contract provides for specific performance and
termination for failure to abide by arbitrator's ruling. (It's a nuclear bomb, but both sides
have the key to turn it off -- so it can be used by ICANN to enforce key provisions
without concern about overreaction.) The monetary aspect just favors wrongdoers with
deep pockets who can afford to pay fines. Specific elements put ICANN deep into
analysis of how registries operate -- to no good effect. And it has never actually been