Shared TLD Daily Digest, Aug 03, 1996 - Part 1

-> WG charter timeline
     by Michael Dillon 
-> Re: Lightweight vs. heavyweight registries
     by Michael Dillon 
-> Re: WG charter timeline
     by Kent Crispin 
-> Re: Lightweight vs. heavyweight registries
     by Kent Crispin 
-> Re: Lightweight vs. heavyweight registries
     by Kent Crispin 
-> Re: WG charter timeline
     by chris@kosh.punk.net (Christopher Ambler)
-> Who is archiving the shared-tld list?
     by nreadwin@london.micrognosis.com (Neil Readwin)
-> Re: WG charter timeline
     by Michael Dillon 


----------------------------------------------------------------------

Date: 2 Aug 1996 00:36:47 -0700
From: Kent Crispin 
Subject: Re: Lightweight vs. heavyweight registries

John R Levine allegedly said:
> I've been pondering the ways that shared TLDs might work, and I see two
> somewhat different ways that the responsibility might be parcelled out:
>
> 	The heavyweight registry model:
>
> There are a bunch of registries each of which holds a subset of the total
> contents of the TLD.  Via the magic of a distributed data base, these are
> merged on the fly and loaded into the domain servers now and then.  Each
> registry is presumably a privately owned business.  Unless there's been a
> lot of progress in distributed databases that I haven't seen, this sounds
> awfully tough to make work reliably.
>
> 	The lightweight registry model:
>
> There's one registry for the TLD, but it's a small and perhaps cooperatively
> owned outfit, analogous to DSMI, the telco-owned registry that manages 800
> and 888 numbers.  The registry has a moderate number of customers, each of
> which can register domains for itself or third parties.  Customers
> communicate using a yet to be defined protocol (which need have nothing to do
> with DNS protocols) to send updates to the registry's database, and have a
> billing arrangement with the registry.  The registry has all the info needed
> to update the domain servers for the TLD.  The customer-registry interactions
> are quite formalized, with the idea that the customers are reasonably clueful
> and can be expected to send in well-formed requests.
>
> Following the 800 model, third parties can switch from one customer to
> another and take their domains with them.  The financial arrangements are
> between the third parties and the customers; all the registry does is to
> accept a request from a new customer to take over an existing domain entry.
>
> Customers would typically be ISPs and various sorts of Net presence providers
> who could offer domain registration by itself or more typically as part of
> the package of services they provide.  A single ISP or presence provider
> would probably sign up as a customer of all of the shared TLDs so it could
> provide one-stop service to its users.
>
> It seems to me that the existence of a lightweight registry solves all sorts
> of data management problems, since it's a neutral party that can manage the
> common database.  There's still plenty of opportunity to make money here,
> but it's moved one level out from the registry to the first level customers.
>
> One fairly critical assumption here is that anyone is allowed to grab any
> available name, so the registry need only make a mechanical check for
> duplication.  This doesn't work so well for TLDs with some sort of
> qualification (e.g., domains open only to registered trademark holders, for
> people who believe in that) since it's not clear to me who the gatekeeper
> would be.  But I expect that in fact most domains will be open to anyone, so
> this should work.

You realize, of course, that the two alternatives you describe are
just points in a design continuum, and not necessarily endpoints either.

Also, the terminology you are using is different from what I have been
using -- what you call the single "lightweight registry" for the
domain I have been calling the "nameserver" for the domain.  What you
have been calling a "Customer" I have been calling a "registry".  And
what you call "third parties" I have been calling "Clients".
However, "nameserver" is not a good term, IMO.  I think we will be
talking a great deal about these three roles, so good names will be
handy.  Let me propose that the role you call "light weight registry"
be called a "coordinator"; that the entity you call a Customer we
christian a "registry", and that we use the term "customer" or
"client" to refer to members of the great unwashed multitude (or
their legal surrogates) who seek to get their choice of domain name
recognized by the internet.

Your model, then, is that the "coordinator" is actually separate
organizational entity that the registries contract with to keep
things straight, and that the "coordination database" is actually not
distributed, but rather centralized.

Personally, I would prefer that the coordinator role be distributed.
I don't think it will actually add any significant amount of "weight"
to the operation of a shared registry, and it significantly simplifies
the organizational situation if all the registries are indeed peers,
and that peer relationship is enforced by the requirement to speak a
certain database protocol.  However, we can debate that as a separate
issue -- I think that a large part of the operation of shared
registries is really independent of that, and I would like to address
the common part before we go off and debate :-)

Consider:

There are (at least) three databases involved, which may overlap.  They
are distinguished by their roles as much as by the data they contain:

1) The "nameserver database" -- the database that contains the
(domainname,IP-addr) mapping.  This database could actually be a DNS
zone file, I guess, or some abstraction of it.  In any case, this
database contains the data that actually gets fed to the DNS
nameservers.  This database has weak time constraints -- it could be
rebuilt or updated once a day, with the previous version serving as
the source of DNS information until a fresh one was ready.  Additions
and deletions to DNS could be delayed by up to 24 hours, but that's
no big deal.  Thus there are no strong concurrency requirements on
this database.

2) The "registry database" (which associates all the client/customer
data with their domain).  The registries maintain this as a partitioned
database -- each registry only really cares about its own customers,
after all.  This database would also contain IP addresses.
Maintenance of this database is a registry's local concern.  There
are no concurrency issues.

3) The "coordination database".  In simplest form, this is just a
database of all (subdomain_name,responsible_registry) pairs in use.
This database could be maintained either as a centralized single
database, with a client-server interface, or as a distribute
replicated database, with a server at each registry.  If it is
distributed, then there are strong concurrency issues.  However, it is
an extremely simple and small database.

Perhaps a hypothetical transaction will clarify my prose:

    Customer C walks into registry R, which services .com, and says "I
    have an IP address, and I want to register domain x.com".  R
    collects C's data and a check, and reserves the name "x" in the
    coordination database (if the reservation fails, R tells C to pick
    another name, or refunds C's money).  But thankfully for C, "x" is
    available.  R spends some time trying to sell C their value-added
    services, and eventully C walks out, a slightly poorer but happy
    customer.

    That night R gets all the (domain,IPaddress) pairs out of his
    registry database that have changed, and mails them to all his
    cohort registries.  The next morning he collects all the changes
    that his cohorts have sent to him, and generates an up-to-date
    nameserver database, which he loads into his nameserver.  It is
    his turn to be the root nameserver for the domain, so he does a
    very careful job...

    Once a month all the cohorts do a full rebuild of the nameserver
    database by pooling the information from their registry databases.

Notice that the only real use for the coordination database in this
scenario is to act as a reservation system.  The situation gets a
little more complicated when you start worrying about things like a
competitor cohort cheating by claiming a bunch of names, or how the
IANA audits things to collect its fees ;-).

Modulo that we will discuss at a later date how the coordination is done,
is what I just wrote consistent with what you have been thinking?

- --
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...


----------------------------------------------------------------------

Date: 2 Aug 1996 01:09:39 -0700
From: shaw 
Subject: Re: .com

Kent Crispin wrote:

>Does anyone know more about the Harvard meeting, just out of
>curiosity?
>

Here are the three key related conferences...

1. November 20, 1995 Conference: "Internet Names, Numbers,
and Beyond: Issues in the Coordination, Privatization
and Internationalization of the Internet" at:

http://ksgwww.harvard.edu/iip/nsfforum.html

2. February 2, 1996 Conference: "Internet Administrative
Infrastructure" at

http://www.aldea.com:80/cix/agenda.html

3. Upcoming September 8-10, 1996 Conference:
"Coordination and Administration of the Internet" at

http://ksgwww.harvard.edu/iip/internet.html

Robert
ITU



----------------------------------------------------------------------

Date: 2 Aug 1996 07:27:34 -0700
From: johnl@iecc.com (John R Levine)
Subject: Re: Lightweight vs. heavyweight registries

I said:

>> It seems to me that the existence of a lightweight registry solves all sorts
>> of data management problems, since it's a neutral party that can manage the
>> common database.  There's still plenty of opportunity to make money here,
>> but it's moved one level out from the registry to the first level customers.

[lots of sensible comments elided]

>    That night R gets all the (domain,IPaddress) pairs out of his
>    registry database that have changed, and mails them to all his
>    cohort registries.  The next morning he collects all the changes
>    that his cohorts have sent to him, and generates an up-to-date
>    nameserver database, which he loads into his nameserver.  It is
>    his turn to be the root nameserver for the domain, so he does a
>    very careful job...

This is exactly the data management problem that I'm worried about.  With
all this mailing around, the changes for data skew are substantially higher
than if there's one authoritative copy of the database. It may be wrong, but
at least it's in one place so errors are easy to spot and correct.

This also puts a considerably heavier responsibility on R than the
lightweight registry model does.  In the lightweight model, R needs only be
able to communicate his updates to the lightweight registry/coordinator,
while in this model R and all his peers have to be prepared to do a complete
database merge.  Given that the R's will be ISPs and the like, from what
I've seen of the level of sophistication of most ISPs, this is a ticket to
disaster.  My ISP does an adequate job of providing bandwidth, but they
can't even get their external routing right, and I cannot imagine them being
up to the task of co-administering a registry.  They have neither the
expertise nor the time.

The lightweight registry model does require that the centralized registry be
trustworthy, but with an appropriate ownership model, that seems a lot
easier to establish than to qualify all of the R's.  ("Hey, all of the sites
in .OINK disappeared!" "Yeah, it was Bogo-net's turn to do the update last
night, they always screw it up.  Try again tomorrow.")

- --
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: 2 Aug 1996 11:11:38 -0700
From: nreadwin@london.micrognosis.com (Neil Readwin)
Subject: Re: Lightweight vs. heavyweight registries

> The "coordination database".  In simplest form, this is just a
> database of all (subdomain_name,responsible_registry) pairs in use.

It is not clear to me that this database has to exist. Let's consider
an alternative transaction:

        Customer C walks into registry R and says "Here's some money,
        get foo.bar delegated to the host at IP address a.b.c.d"

        Registry R updates the "nameserver database"

        C and R part forever.

This would move the concurrency problems to the registry and nameserver
DBs (I'm not claiming that this is a good thing).

An aside - if the coordination DB does exist then "whois" starts to
look more like DNS itself - to find the contact info etc you would have
to query the coordination DB to find the registry, just as you now
query the root servers to find the NS for a second level domain. Is it
desireable to have this data distributed?

>    Once a month all the cohorts do a full rebuild of the nameserver
>    database by pooling the information from their registry databases.

I know this isn't fair, but this sounds a lot like "The incremental
update scheme will obviously break, so here's a kludge to repair the
damage from time to time." I think I have a better kludge :-)

Since the DB will usually be small (a few megabytes or tens of
megabytes) it shouldn't be that hard to generate a simple checksum of
it and have the registries compare that after each incremental update
(assuming they care whether they are right, that is). Neil.


----------------------------------------------------------------------

Date: 2 Aug 1996 11:28:07 -0700
From: nreadwin@london.micrognosis.com (Neil Readwin)
Subject: Re: Charter

> it is especially important that there be mechanisms in place to prevent
> cheating, pre-claiming desirable names, and so on.

Anyone else can still pre-claim names by paying the registries to do it
for them, so why shouldn't the registries be allowed to do it too :-)
The registries only have an advantage over random end-users at the
moment the TLD is first opened, and my feeling is that it actually
won't be that big a deal.

Anyone know about precedents wrt phone numbers? The same problem
should occur with any new area code (some numbers are better than
others, right?), not just 888 etc. Neil.


----------------------------------------------------------------------

Date: 2 Aug 1996 15:39:55 -0700
From: Kent Crispin 
Subject: Re: Lightweight vs. heavyweight registries

John R Levine allegedly said:
>
[snip]
>
> >    That night R gets all the (domain,IPaddress) pairs out of his
> >    registry database that have changed, and mails them to all his
> >    cohort registries.  The next morning he collects all the changes
> >    that his cohorts have sent to him, and generates an up-to-date
> >    nameserver database, which he loads into his nameserver.  It is
> >    his turn to be the root nameserver for the domain, so he does a
> >    very careful job...
>
> This is exactly the data management problem that I'm worried about.  With
> all this mailing around, the changes for data skew are substantially higher
> than if there's one authoritative copy of the database. It may be wrong, but
> at least it's in one place so errors are easy to spot and correct.

Hmm -- I actually have been thinking of this part of the problem as
completely straightforward and rather simple, because there are no
real time constraints.

> This also puts a considerably heavier responsibility on R than the
> lightweight registry model does.  In the lightweight model, R needs only be
> able to communicate his updates to the lightweight registry/coordinator,
> while in this model R and all his peers have to be prepared to do a complete
> database merge.  Given that the R's will be ISPs and the like, from what
> I've seen of the level of sophistication of most ISPs, this is a ticket to
> disaster.  My ISP does an adequate job of providing bandwidth, but they
> can't even get their external routing right, and I cannot imagine them being
> up to the task of co-administering a registry.  They have neither the
> expertise nor the time.

Let's suppose, for discussion purposes, that responsibility for
supplying an accurate zone file is rotated around the cohorts (say
once a month), and that once a night all the cohorts mail their zone
file updates to the designated maintainer of the month.  They use a
stylized format, of course, and it is in their best interest to both
be very accurate, and to ensure that their updates reach the
designee, perhaps requiring return receipt of some sort.  The designee
waits until all the update deadline has arrived, then runs a
perl script to merge in the updates.  This doesn't have to be a perl
script written by them -- it would be part of the STLD package.  The
result of the run is a correct zone file.  If an update file is
damaged or incorrect in some way, the updates for that registry don't
get done, a mail message is sent back to the registry, etc.

This all seems extremely simple and low tech to me, and a turnaround
time of 24 hours on getting a domain name installed would be a *lot*
better than what we have now.  Absolute consistency and so on doesn't
seem critical here -- things can be fixed in the next days run, and
all the competing registries will be able to check the results and
verify that "bogo-net" didn't screw up.

> The lightweight registry model does require that the centralized registry be
> trustworthy, but with an appropriate ownership model, that seems a lot
> easier to establish than to qualify all of the R's.  ("Hey, all of the sites
> in .OINK disappeared!" "Yeah, it was Bogo-net's turn to do the update last
> night, they always screw it up.  Try again tomorrow.")

This is the good part about competition -- if Bogo-net was
incompetent, then presumabley they won't remain in the business for
long.  :-)

About the "centralized registry" vs other models -- any part of the
operation of STLD registries could be subcontracted in various ways --
actual TLD DNS nameservers, for example could be totally separate from