This is a preliminary input for the current policy-development process on “new registry services” that was prepared by ALAC members; Jonathan Weinberg has provided input and comments in response to earlier drafts. The ALAC is currently soliciting comments on this text. Comments can be submitted either to CircleID (see comment section at the end of this page), or to the ALAC’s public comment address at [email protected].

ALAC Remarks on a Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry:

Introduction

In the present document, we will focus on substantive criteria to be used by ICANN in evaluating requests to review proposed changes to the architecture or operation of a gTLD registry. We are, however, not stating any opinion about the kinds of requests that ICANN currently has the authority (or obligation) to consider.

Procedural Remarks

On the procedural side, we generally believe in accountable, transparent and objective processes that ensure that policy is applied in a neutral manner. In particular, the process should provide opportunities for all relevant parties (including GNSO constituencies and Advisory Committees) to get involved, and should, in particular, incorporate opportunities for meaningful and early public comment.

Substantive Remarks

Burden of proof; principles. As a fundamental principle, what some call the “first law of the Internet” should be applied to proposed registry changes: Any privately beneficial activity should be allowed unless it is shown to be publicly detrimental; those who want to forbid an activity bear the burden of proving public harm.

In this scheme, bad ideas are not forbidden, but tried, and doomed to ? maybe unexpected ? failure. Whether a proposed change is “good” or “bad”, or wanted by the Internet community, is not decided by some body a priori, but measured by market success ? or failure: Where the community’s interest is measurable in market terms, “regulatory” decisions can and should be avoided.

Conversely, where market feedback cannot accurately define the community’s interest because of the absence of a competitive market, or because of the imposition of spillover costs, the community’s interest must be defined in another way. For example, imagine that a registry imposes a change in behavior affecting all incumbent registrants. Those registrants would have to incur high switching costs in order to change to another TLD; that fact distorts the market’s response to the registry change. For another example, imagine that a change in the DNS responses returned by the registry leads to a change of software behavior for users who have not changed their software or configuration. Since users, in their roles as consumers of DNS data, cannot control this change through their purchasing decisions, they cannot provide market feedback. And they are stuck with the changed software behavior, since reconfiguring or modifying their client software will likely be unacceptably costly to them.

Whether or not market feedback can provide an accurate barometer of the desirability of the proposed change should be a crucial test within the initial quick-look analysis of any proposed change that ICANN assesses. Where a proposed change fails this test, it should be the registry’s burden to prove that no harm is caused by the proposed change.

Harm. We focus on three areas of significant harm that can be caused by changes to registry architecture or operations: Changes that affect the network’s openness for innovation; changes that cause cost at the edges but benefits for the registry; and changes that enable registries to leverage their monopoly position into different markets where they can then compete unfairly.

One of the key elements in keeping the network open for innovation is the protocol neutrality of the naming and addressing framework: When new protocols are introduced, the DNS protocol in general needs no change ? it is flexible enough to provide naming services for new protocols. The introduction of HTTP, for instance, required no change to the DNS.

It is extremely rare that the DNS has special provisions for specific protocols, the most prominent example being MX records which enable e-mail service for domain names which are not mapped to IP addresses themselves. These special provisions, though, are designed so they do not interfere with the behavior of the DNS protocol as used by other protocols; they can be introduced without causing harm to (in fact, without even being noticed by) Internet users at large, and they do not harm the Internet’s openness.

Harm is caused, though, when registries introduce new services and change DNS behavior in a way which caters to the needs of some specific protocol, but makes the DNS less useful for other existing protocols, and for future innovation. As one committee member put it, the protocol-neutral, end-to-end net ? of which the protocol-neutral DNS is a key ingredient ? offers a neutral background for line drawing, oil painting, and collage. Sure a grid on the blank canvas would help those making mechanical drawings at the right scale, but it’s just noise to the rest, who now need to paint an extra layer to cover it up.

A more general characteristic of harmful registry changes is to cause cost at the network’s edge, while benefiting the registry, by , e.g., breaking existing expectations, specifications, or implementations. Effectively, such scenarios would mean that registries attempt to profit without bearing the actual cost of rolling out a change; the economics here are analogous to those of environmental pollution. Just as environmental pollution can be completely rational behavior (unless penalized by law or liability), it is rational for registries to attempt to profit, while shifting the cost to others. ICANN should strive to prevent this from happening.

Registries should not be allowed to leverage their monopoly position for wholesale domain name registrations into other markets. Such leverage can occur in many ways, and it is crucial that ICANN engage in thorough and thoughtful analysis of these questions.

To give just one example, a registry replacing error responses by pointers to a registry-operated service is using its monopoly to override end users’ choice about how they want errors to be handled. Error handling, as implemented in client software, is no longer the object of competition with this change implemented. Additionally, the registry would invade the pay-per-click search engine market through a route available only to the registry. At the same time, routes into that market which are based on end-user decisions (browser plugins, for instance), are disabled.

Also, registries should not be permitted to establish new monopolies where this can be avoided. Instead, preference should, wherever possible, be given to designs in which similar services can be provided by multiple parties; designs which permit market-based pricing of services should be preferred over designs that lead to monopoly pricing.