It looks as if ICANN is going to require applicants for new TLDs to agree (in advance) not to negotiate a changed contract with ICANN. We agree that streamlining the process is in everyone’s interest. Along those lines, we are proposing a substantially thinner contract that ICANN and new registries could use. Existing registries should also be allowed to sign up to this contract, if they wish.

We strongly believe that a thinner contract is needed—for several reasons. First, registries under contract with ICANN are now in the position of needing to ask for permission before innovating in any way. This has led to near-death experiences for several of the registries, as business plans and the realities of the marketplace change. This cannot be a desirable result, and imposes a great deal of pressure on ICANN staff. Second, contracted registries are subject to many onerous provisions in the existing contract that were the inventions of ICANN’s prior (and very well-meaning) General Counsel. We believe that these provisions (such as reporting obligations and performance specifications) are unnecessary. More open competition among registries would encourage innovation and better customer service, and the existing requirements have been unenforced (and are unenforceable). Third, the existing weighty contracts have led to serious questions about ICANN’s legitimacy. An ICANN that does not pretend to be a regulatory agency (and recognizes that no one gave it the power to be one) will not be such a large target for criticism. An ICANN that retains the central consensus policy regime that gives it legitimacy will be a long-lived ICANN.

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
(see here for model before deletions)

1. Removed unnecessary definitions.
2. 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 their needs.
3. 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.
4. 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.
5. Removed startup period language, which added complications without benefits.
6. Removed ICANN as beneficiary of escrow; registry should be able to designate party to run registry if it fails to abide by this Agreement.
7. Removed existing registry fee provision because unnecessarily complicated; substituted agreement to contribute to ICANN on an equitable scale.
8. Revised scope of consensus policies to match revisions to the rest of the agreement.
9. Removed price cap for registry services; substituted agreement not to charge more for renewals than for initial registrations.
10. Removed whois and bulk access obligations; these issues should and will be the subject of consensus policies.
11. Removed expiration provisions; substituted automatic renewal if not in breach.

Items Removed From Appendices
(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 Information

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 ICANN.

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 change.

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 particular way. Locked in terms might conflict with consensus privacy policy.

O: Whois Specification—Public Whois

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 used.