-> business model for shared tlds
by Kent Crispin
-> Re: business model for shared tlds
by johnl@iecc.com (John R Levine)
-> Re: business model for shared tlds
by Kent Crispin
----------------------------------------------------------------------
Date: 5 Aug 1996 01:44:52 -0700
From: kslim@merlion.singnet.com.sg (KOON SANG LIM)
Subject: FW: Re: Lightweight vs. heavyweight registries
Dear Perry
I thought we have the Charter for Shared-TLD since the commencement of this
list(defined by Higgs)
KS Lim
- ---------------Original Message---------------
Michael Dillon writes:
> There is a major, major problem with your proposal and it will never work
> because of that.
>
> We have no WG charter, thus we have no WG, thus we have no possibility
> of setting an Internet standard, thus we are wasting our time.
Get off it. Producing a WG charter takes about half an hour. I've done
a couple at this point. Its hardly difficult. Just sit down and write
one if you feel like it.
Perry
----------------------------------------------------------------------
Date: 5 Aug 1996 17:26:12 -0700
From: Kent Crispin
Subject: business model for shared tlds
Jon Postel said, in a mail message a while ago:
> Hi.
>
> I have said that the technology exists for operating shared TLDs.
>
> I don't understand any business model that works, though.
>
> If some companies want to get together and be separate but somehow
> coordinated registries for a shared TLD, i am all for it.
>
> I just don't see why they would ever do that, and i don't think it
> is reasonable to try to force companies to do it.
>
> --jon.
I have been thinking about this question for some time. In Jon's
draft, section 6 he describes various requirements that a registry must
meet in order for it to receive IANA's blessing. The IANA (actually
an ad hoc committee) will approve or disapprove of an application to
run a registry. In 7.3 hands are waved -- the IANA will be
authorized to "promulgate reasonable adjudication policies which
should include an arbitration provision" for termination of a
registry. And the beginning of section 8 has a note which states
in part:
There is a concern that the presence of a funding path creates a
tying arrangement between for-profit organizations and a set of
non-profit organizations which up to now have not been legally,
financially, or otherwise encumbered by the actions of these
registries.
It strikes me that, while the funding path certainly magnifies the
legal exposure, it is really approval/disapproval/termination that
opens the door. In the long run I think the inevitable consequence of
the procedures described in the Postel draft is a large IANA
bureaucracy whose primary purpose is dealing with legal issues. This
would be a bad thing.
Here is an alternative approach that I think eliminates most of this
problem:
Signed and completely filled out applications for registry status
for any TLD are submitted to the IANA, with a fee large enough to
discourage completely frivolous applications (say in the
$1000-$10000 range). Approval is essentially automatic, and
grants registry status for a specified term (say 3 years).
The application form is a contract which stipulates the following:
The registry is authorized by the IANA to register domain names
for the specified TLD(s) for the specified time. The IANA will
authorize any organization for any TLD whatsoever, as long as the
fee is paid. "Authorized by the IANA" will be explained a little
further on.
If it is a new TLD, the applicant agrees that the TLD is not a
name that is a trademark or otherwise legally encumbered, and
specifically authorizes the IANA to approve applications for other
registries to service that TLD. In other words, there are *no*
exclusive contracts. A trademark holder who feels that a registry
has usurped its name is free to sue and force the registry out of
business. However, the trademark holder will never be able to
operate an exclusive registry with its trademark.
Further clauses in the application specify the ground rules for
cooperation between registries -- the idea is that the
application, besides being a contract between the applicant and
the IANA, is also a contract between the applicant and all other
registries, current and future, servicing the same TLDs.
These ground rules specify how a registry may seek redress against
other registries for failure of performance. They also specify
that a registry must make its DNS information available to all
other registries that service the same TLDs within a reasonable
time. Registries that fail to disgorge their information in a
timely fashion will be open to legal action through terms of the
application contract. Mechanism for supplying the information is
not specified, but it is likely that a set of
protocols/software/procedures will be quickly developed and
standardized.
The application may include clauses specifying other fees payable
to IANA.
Supposing a registry breaks a rule that cannot realistically be
enforced by the other registries for a TLD (for example, not
paying a fee), the IANA has the following enforcement sanction
available to it: inform peer registries to no longer accept DNS
updates from the offending registry. If the offending registry is
the only one for the TLD, inform root nameservers to no longer
refer to the offenders nameserver.
Failed registries customers could be handled via procedures
similar to what is in the current Postel draft.
This scheme, I think, essentially indemnifies the IANA, because it has
few discretionary actions. It approves all correct applications, and,
except in a few simple, cut and dried circumstances, doesn't rescind
its blessing. Success or failure of a registry is left to the
marketplace.
As far as a business model: the InterNIC and the AlterNIC and anyone
else are free to compete on the quality of their service. The
InterNIC will have an advantage because it is larger and better
known, but that's true in any business.
Furthermore, small individual ISP's will be able to offer direct
domain registration as a service to their customers. They already
have the infrastructure in place, and this would be an added value
they could offer that could compete with the InterNIC. Especially if
the application fee were relatively low, they could offer
registration services for several popular TLDs. Very large companies
could offer registration services for essentially all TLDs.
It is true that the people who are counting on monopoly profits from
their ownership of a sexy and proprietary TLD would be disappointed by
this proposal. However, those who have a business plan in place with
an organized scheme for a domain name would still have a substantial
head start over any competition.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
kc@llnl.gov
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
kc@llnl.gov
----------------------------------------------------------------------
Date: 5 Aug 1996 20:01:24 -0700
From: johnl@iecc.com (John R Levine)
Subject: Re: business model for shared tlds
> If it is a new TLD, the applicant agrees that the TLD is not a
> name that is a trademark or otherwise legally encumbered, and
> specifically authorizes the IANA to approve applications for other
> registries to service that TLD. In other words, there are *no*
> exclusive contracts.
This is very much the model that I'd envisioned, with providers making their
money by providing useful and innovative services, not by artificially
cornering a piece of the namespace. (Yes, that's what the Internic did, we
all seem to agree that it was a mistake.) We can expect most ISPs to sign
up to be registries for most domains, with perhaps some intermediate
organizations that act as registrars for small ISPs. (The telephone analogy
is US Intelco, a company which handles a lot of network stuff like calling
cards for small telcos.)
I'm trying to figure out how TLD domain servers work in this model. I'm not
worried about root servers, we have plenty of those and in any event serving
the root domain is and always will be trivial, but there's the issue of
who's going to run the servers and (referring to my previous thread about
light-weight registries) who's going to do the database merges and handle
name reservations.
For servers, I can see two problems: too few servers and too many servers.
An obvious plan might be that every registry has to run a TLD server for the
domains it registers. But if there's only one registry, that's only one
server, and that's not enough. Yet if you have 500 registries, that's far
too many servers. (Remember, you want to keep your servers in sync when you
update.)
I'm still trying to think of a workable solution other than a jointly owned
per-TLD central database.
- --
John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869
johnl@iecc.com "Space aliens are stealing American jobs." - Stanford econ prof
----------------------------------------------------------------------
Date: 5 Aug 1996 23:48:17 -0700
From: Kent Crispin
Subject: Re: business model for shared tlds
John R Levine allegedly said:
>
> > If it is a new TLD, the applicant agrees that the TLD is not a
> > name that is a trademark or otherwise legally encumbered, and
> > specifically authorizes the IANA to approve applications for other
> > registries to service that TLD. In other words, there are *no*
> > exclusive contracts.
>
> This is very much the model that I'd envisioned, with providers making their
> money by providing useful and innovative services, not by artificially
> cornering a piece of the namespace. (Yes, that's what the Internic did, we
> all seem to agree that it was a mistake.) We can expect most ISPs to sign
> up to be registries for most domains, with perhaps some intermediate
> organizations that act as registrars for small ISPs. (The telephone analogy
> is US Intelco, a company which handles a lot of network stuff like calling
> cards for small telcos.)
>
> I'm trying to figure out how TLD domain servers work in this model. I'm not
> worried about root servers, we have plenty of those and in any event serving
> the root domain is and always will be trivial, but there's the issue of
> who's going to run the servers and (referring to my previous thread about
> light-weight registries) who's going to do the database merges and handle
> name reservations.
>
> For servers, I can see two problems: too few servers and too many servers.
> An obvious plan might be that every registry has to run a TLD server for the
> domains it registers. But if there's only one registry, that's only one
> server, and that's not enough.
Perhaps it doesn't matter. Suppose I get a wild idea that .qxv is an
incredibly clever TLD, and I register it, and I sit at home with my
tiny Linux box serving all comers (my wife, daughter, and a few
friends). It really doesn't make a whole lot of difference if my TLD
disappears. OTOH, if by some incredible quirk I am a brilliant
visionary, and .qxv is wildly popular, other ISP's will grab some of
that business, and once again, it doesn't matter what happens to me.
> Yet if you have 500 registries, that's far
> too many servers. (Remember, you want to keep your servers in sync when you
> update.)
It surely doesn't matter if the servers are in exact sync -- even now,
primary and secondary name servers can be out of sync for extended
periods of time. But your point holds, nonetheless -- if .com were a
shared TLD, it could have literally thousands of registries (think of
all the fees the IANA could collect).
The .com situation is certainly an instructive case to consider. It could
be that most of the ISPs in the world would sign up to be a registry for
.com. And the set of cohort registries could change on a daily basis, as
ISPs added or dropped .com, or went out of business, or whatever.
The aggregate transaction rate could be thousands per day.
However, this worst-case scenario is, I believe, completely
unrealistic. It would take more than a Linux box to be able to be a
registry for .com, especially if being a registry meant that you had
to be capable of supporting primary name service for the entire TLD --
in fact, it would take more technical infrastructure than many ISPs
would want to devote.
> I'm still trying to think of a workable solution other than a jointly owned
> per-TLD central database.
For .com some fairly high powered solution would be necessary. But
for a middling size TLD, with maybe a transaction rate of 100/day and
10 registries, it doesn't seem like much of a problem to me. Each
registry would process an average of 10 applications/day, and get
nameserver updates. Each application would require 9 reservation
messages -- presumably collisions would be extremely rare. So that's
on the order of 1000 messages/day for coordination. All the
transactions are automated. Once a day an incremental zone update is
sent to all the cohorts -- about 100 transfers, total. The merge is
handled automatically by the DNS software.
Using the same stupid algorithm for a much larger TLD, with an
aggregate transaction rate of 1000/day, with 100 registries handling
10 applications/day, there would be 100,000 coordination messages
(each of the 1000 applications requires a reservation being sent to
each of the 100 registries), and about 10,000 incremental zone
transfers/day. This is, in my opinion, too much traffic, and
something a little more clever than an n^2 algorithm would have to be
devised. But that's not a big deal -- slightly more intelligent
software could surely get this down to n*log(n), and perhaps maybe
even be linear. I am no expert in distributed database, but I believe
that they eat this kind of stuff for desert. In fact, as I think
about it...
The point is, it's all automated. The design should not care whether
the database is centralized or distributed -- that aspect should be
transparent.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
kc@llnl.gov
