-> Law Review Article on DNS
by shaw
-> Re: business model for shared tlds
by johnl@iecc.com (John R Levine)
-> Re: business model for shared tlds
by Kent Crispin
----------------------------------------------------------------------
Date: 8 Aug 1996 10:02:37 -0700
From: shaw
Subject: Law Review Article on DNS
The John Marshall Law Review, Volume 29, Number
3, Spring 1996 issue has an article:
"Cybermarks: A Proposed Hierarchical Modeling
System of Registration and Internet Architecture
for Domain Names."
by G. Andrew Barger, an Intellectual Property
Attorney at Chrysler Corporation.
Have only glanced through it but have already seen
some pretty serious misunderstandings. For the info
of the list...
Robert
ITU
----------------------------------------------------------------------
Date: 8 Aug 1996 18:17:39 -0700
From: johnl@iecc.com (John R Levine)
Subject: Re: business model for shared tlds
>If we assume a replicated database the problem gets a whole lot
>easier. Here's an algorithm, which I will dub the "rotating lightweight
>registry" algorithm:
>
>The registries are numbered 1 to N. Each registry keeps a copy of the
>registration database. Each day the "master" number is incremented
>mod N, so, for example, on day 5 registry number 5 is the
>coordination master.
>
>All coordination protocol messages go to the master, which functions
>as a light-weight registry. When the day ends the master sends a
>database update package to all the other registries, and then passes
>the torch to the next registry. Since the selection of master is
>just a function of the date, there is never any doubt who the master
>is.
>
>I think this scheme meets all the criteria of fairness, efficiency,
>and reliability.
Hmmn, if there's more than a very few registries, it sounds to me pretty
unwieldy. Consider my example of a popular domain with 365 registries, so
each one only gets to be the master once a year. How likely is it when
master day comes around, the master part of a particular registry's software
will be correctly installed and working? Same problem I discussed before:
all registries have a strong interest in being able to register names, but
they have only a faint interest in being the coordinator.
I need to go look at my TODS and see if there's been any real work on
distributed databases with large numbers of databases kept in sync.
- --
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: 8 Aug 1996 23:13:02 -0700
From: Kent Crispin
Subject: Re: business model for shared tlds
John R Levine allegedly said:
>
> >If we assume a replicated database the problem gets a whole lot
> >easier. Here's an algorithm, which I will dub the "rotating lightweight
> >registry" algorithm:
> >
> >The registries are numbered 1 to N. Each registry keeps a copy of the
> >registration database. Each day the "master" number is incremented
> >mod N, so, for example, on day 5 registry number 5 is the
> >coordination master.
> >
> >All coordination protocol messages go to the master, which functions
> >as a light-weight registry. When the day ends the master sends a
> >database update package to all the other registries, and then passes
> >the torch to the next registry. Since the selection of master is
> >just a function of the date, there is never any doubt who the master
> >is.
> >
> >I think this scheme meets all the criteria of fairness, efficiency,
> >and reliability.
>
> Hmmn, if there's more than a very few registries, it sounds to me pretty
> unwieldy. Consider my example of a popular domain with 365 registries, so
> each one only gets to be the master once a year.
I can imagine that there would be literally thousands of registries
that would want to be able to handle .com.
> How likely is it when
> master day comes around, the master part of a particular registry's software
> will be correctly installed and working?
Fairly high, I would think. Remember that one of the conditions of
being a registry would be the ability to handle the coordination
database. I would imagine that all the preexisting registries would
have a pretty high interest in being sure that the newcomer didn't
screw things up. Also, I just picked the one day interval out of a
hat. How about every 6 minutes? That way you would go through 240
different registries a day. Or you could switch registries every 10
transactions -- the update packet for 10 transactions would be only a
couple of kilobytes (when you include public keys and other overhead),
and sending a 10KB packet every 6 minutes is nothing. Right now
apparently .com does around 2000 additions per day, that's on the
order of 1/minute. No big deal.
> Same problem I discussed before:
> all registries have a strong interest in being able to register names, but
> they have only a faint interest in being the coordinator.
I guess I don't see this as being a big factor, for a couple of
reasons. First, they only have a faint interest in paying their
electric bill, but they certainly will pay it. Second, it is
actually in their best interest to do a good job. If the TLD as a
whole isn't well managed they lose business too. Third, your
concern, as I recall, stems with some experience you had with PBX
operators? It's not clear to me that the cases are that comparable.
It's interesting to consider that the fact the TLD is shared ties the
fates of the registries together regardless. If .abc has a 40
registries, and one of them makes the evening news because of their
sleazy business practices, all of them could be hurt by the bad
publicity. While they compete against each other, the different TLDs
compete as a whole. Which is a better one to be in, .com, .biz, .org,
or .inc? This will be the question people ask first. Only secondarily
will they decide whether to go with "Domains R Us" or "Petes House of
Domains" across the street.
Hmm, and it's also interesting to consider how DNS supermarkets like
"Domains R Us" might effect the economics of the situation.
> I need to go look at my TODS and see if there's been any real work on
> distributed databases with large numbers of databases kept in sync.
Ah yes. How do we keep all the other registries up to date? Damn.
This is a hard problem.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
