ICANN ICANN Email List Archives

[At-Large Advisory Committee]


<<< Chronological Index >>>    <<< Thread Index >>>

[alac] [fwd] CORRECTION: Preliminary ALAC remarks on new registry services. (from: roessler@does-not-exist.org)

  • To: alac@xxxxxxxxx
  • Subject: [alac] [fwd] CORRECTION: Preliminary ALAC remarks on new registry services. (from: roessler@does-not-exist.org)
  • From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
  • Date: Sat, 17 Jan 2004 19:50:33 +0100

After final consultation with Vittorio, this just went to the
council.

(The discarded material in the first attempt came from
change-tracked edits that had been wrongly included by OpenOffice
during export to plain text.)

It would be good if this text could be put up for public comment on
the ALAC website ASAP.

Regards,
-- 
Thomas Roessler  <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/





----- Forwarded message from Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx> -----

From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
To: council@xxxxxxxxxxxxxx
Date: Sat, 17 Jan 2004 19:46:46 +0100
Subject: CORRECTION: Preliminary ALAC remarks on new registry services.
Mail-Followup-To: council@xxxxxxxxxxxxxx
Bcc: roessler@xxxxxxxxxxxxxxxxxx

On 2004-01-17 19:43:04 +0100, Thomas Roessler wrote:

> please find below some preliminary remarks from the ALAC on the
> ongoing "new registry services" PDP.  We are also soliciting
> public comments on these remarks, and will follow up with
> information about any input we receive about this.

Please disregard the version of the text that just went out to the
list -- some discarded material from earlier drafts had survived in
that version.

Apologies,
-- 
Thomas Roessler  <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/





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 intial 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 benefitting 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
t he 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, whereever
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.


----- End forwarded message -----



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy