ICANN ICANN Email List Archives

[settlement-comments]


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

Suggestion for contract change

  • To: <settlement-comments@xxxxxxxxx>
  • Subject: Suggestion for contract change
  • From: "Kieren McCarthy" <kieren@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 26 Oct 2005 13:25:15 +0100

I would like to argue for a small but important change to be made to the dotcom 
contract - and one that also impacts all recent ICANN contracts (.net, .mobi, 
.jobs, .travel): the issue of presumptive ownership rights.

This allows the contract holder to have first choice on continuing the contract 
- so long as they haven't broken any of the contract's conditions.

I understand that this clause greatly increases a company's ability to raise 
essential capital, but even so I think it is a backwards step which will result 
in stagnation rather than innovation, and should be replaced with a more 
intelligent, free-market approach.

The whole concept of the free market approach is that it keeps people on their 
toes through competition. Conversely, any area where a company has complete 
control is likely to be less innovative and even degrade because there is no 
impetus for that company to spend time and money improving it.

The argument consistently put forward is that the competition in the DNS space 
exists in the range of top-level domains available. I would say that this is an 
academic argument and not one borne out by real-world statistics. It is 
theoretically correct in terms of existing economic models but why wait for an 
economist to draw up a new model before simply recognising what is going on out 
there?

By creating a contract that requires a company to *break* conditions before it 
loses ownership is defensive governance. It requires resources to be directed 
in a destructive manner and, if applied, will inevitably result in tensions 
between the overseer and the registry owner. It also takes the very foolish 
route of trying to predict in a contract what conditions will be most 
applicable on the Internet in the future. 

I have yet to find one example of someone getting a prediction about the 
Internet in five years' time correct. And that situation is likely to remain 
for at least the next ten years for this very new medium.

Instead, I would suggest that the governance framework allows for the indirect 
interjection of a third party into this contract.

Any third party would be given the right to put forward a case as to why it 
would be beneficial to a particular registry's customers if it were in charge. 
It could, for example, promise a price reduction or expanded services not 
currently offered by the incumbent, or a guarantee of greater reliability.

An independent body would review this case and if it felt there was a real 
chance that the registry and its customers would benefit from the change, it 
can recommend that the contract be put out to tender at its expiration.

This approach would have several positive effects. First and foremost, it would 
force existing registry owners to watch other companies and keep up with 
developments and innovations. 

Secondly, it would remove the defensive - and expensive - governance approach 
currently in place, and the tension associated with that approach. Costs would 
be moved away from a central control point to competitive companies keen to win 
new business.

And thirdly, it would give companies greater impetus to innovate in the hope of 
taking over an existing registry.

The altered contract would thus read that a registry owner has presumptive 
rights so long as they don't breach the contract **or a challenge is made on 
the registry by a third party that is accepted by an independent review body**.

The registry owner's ability to raise capital would not be impinged because 
they would only lose ownership if they were inefficient and any investors would 
want the company to be run efficiently in the first place.

That's my suggestion for an alteration to the existing contracts.



Kieren McCarthy








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