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

-> Centralized or decentralized Whois server ?
     by huitema@bellcore.com (Christian Huitema)
-> Re: New Non-Shared TLD's Create More Monopolies
     by johnl@iecc.com (John R Levine)
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: Mandated shared registries
     by Matthew James Marnell 
-> [ADMIN] Test
     by Simon Higgs 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: Centralized or decentralized Whois server ?
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Michael Dillon 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Michael Dillon 
-> Re: Centralized or decentralized Whois server ?
     by Michael Dillon 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
     by johnl@iecc.com (John R Levine)
-> Re: New Non-Shared TLD's Create More Monopolies
     by Michael Dillon 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Keith Winstein 
-> Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 
-> Re: New Non-Shared TLD's Create More Monopolies
     by Kent Crispin 


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

Date: 20 Aug 1996 03:29:01 -0700
From: Alan Barrett 
Subject: Re: New Non-Shared TLD's Create More Monopolies

Randy Conrad said:
> Thanks for the clarification.  I'm interested in getting up and
> running as fast and reliably as possible, thus I was assuming that the
> CDB (which is what I guess we're calling it) would not do any of the
> checking to see if the nameservers were up.

My previous message essentially argued for a separation between "reserve
the name" and "register all the details" at the customer/registry
interface.  That in turn requires a similar separation at the registry/CDB
interface.

We probably do not want the CDB to do any checking to see if nameservers
are up, but I would almost certainly want the registries to do such
checking.

> The scenario I envisioned was:
>
> 1) person chooses name
> 2) person goes to registry to request name, providing registration data
> 3) registry requests name
> 4) if name exists, goto step 1
> 5) CDB allocates name with registration data at registry and builds zone file
> 6) person pays registry
> 7) person sets up DNS service
> 8) zone file distributed to appropriate servers
>
> Is adding the state, timers, and server complexity valuable enough to
> warrant the addition of the NS checking code (no opinion, just
> asking)?

I don't think we need NS checking code in the CDB.  I do think we need the
separation between "reserve" and "commit".

I often see collisions where two or more parties try to register the same
name nearly simultaneously.  In too many such cases, the losers neglect to
clean up the zones that they had set up prior to the registration attempt.
We should design a new system that does not have that failure mode.

- --apb (Alan Barrett)



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

Date: 20 Aug 1996 05:55:40 -0700
From: perry@piermont.com
Subject: Re: New Non-Shared TLD's Create More Monopolies


Kent Crispin writes:
> Nope.  I'm suggesting a perl script that runs rwhois, gets the data,
> and inserts all of it into a local whois database.

Having built crap like that before, I'll tell you that one's life is
always much, much happier when you have a real database. Perl hacks
from text taken off the net are for when you have no choice.

> I can accept (though grudgingly) that a centralized database for
> synchronization is small enough and simple enough that it is unlikely
> to become a serious problem.  However, when this central database
> also becomes the authoritative repository for all the contact
> information I begin to worry.

I don't understand this worry. It doesn't prevent you from storing the
data elsewhere, nor does it give the central DB any advantage if it is
under a contractual obligation about what it can and can't do.

The central DB is NOT some mammoth organization. Its maybe Bill
Manning's summer intern and a couple of donated machines sitting in a
couple of machine rooms across the country from each other. Relax.

Perry


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

Date: 20 Aug 1996 06:12:02 -0700
From: perry@piermont.com
Subject: Re: New Non-Shared TLD's Create More Monopolies


Kent Crispin writes:
> > > A 25 line perl script that takes about 30 minutes to write will
> > > handle this quite easily.
> >
> > Not very well, I'd say.
>
> It doesn't have to be perfect.

I'm afraid it does. The amount of time and effort involved when things
fuck up is giant, and is what will end up costing everyone the most
time and money. Doing it right is cheaper than doing a silly hack.

> The only time this kind of interface would be used is when a user
> changes registries.  That is going to involve a certain amount of
> human interaction and checking no matter what -- you wouldn't want
> me calling up your registry and switching your domain to a registry
> in Timbuktu.

Thats what public keys are for. If you involve humans, the process
will be *less* reliable, especially if the way you get contact
information is over unauthenticated "whois" queries augmented by perl
scripts. I don't want any humans involved in the central DB at all, if
possible. The CDB gets called when one of the registries notices that
there is a technical problem, or when someone wants to become a
registry. Humans cost money, introduce error, and make you a better
target for lawsuits.

> Most important is the distribution of the *authority* for the data.
> The registries should have (IMHO) the authoritative data for their
> customers.  The distributed character of the data follows from this
> principle.

What does 'authoritative' mean?

The only 'authoritative' information is the information sitting in the
DNS, since its the only stuff that matters in the last analysis. You
can call anyone's copy of the database 'authoritative' for laughs, but
that doesn't matter -- what matters is what gets cut to produce DNS
entries.

> Contracts can be developed that will avoid that, you're right.
>
> But then, contracts with whom? With the registries? With the IANA?

Presumably both and more.

> I can certainly see how contracts could be devised that would work
> for a while.  But NSI has a contract with NFS, does it not?

A cooperative agreement, and nothing in it forbids the current behavior.

> People need DNS to be reliable, but it is designed to work very well
> with non instant updates.  And the reliability constraints on
> registries are of a totally different magnitude.  A turnaround time of
> a week is more than adequate.

Nope, it isn't. Something fucks up your primary DNS entries, you need
it fixed NOW. The InterNIC already takes too long on this.

> > There is no reason not to have the CDB placed on a replicated database
> > system such that even if one of the cities with one of the CDB
> > machines was nuked the whole thing didn't continue just fine, but
> > there is good reason not to operate without a centralized database.
>
> Hmm.  Your last clause means "there is good reason to operate a
> centralized database".  The only good reason I've seen so far is to
> support a reservation protocol on names,

No. You need something to cut the masters that generate the DNS. You
also want a central database containing authorization information on
who can and can't switch a zone from one registry to another.

Let me be blunt. I wouldn't run a company DNS with 500 entries without
a real DBMS any longer. I certainly am not going to support some ad
hoc crap to run the global DNS. We want a real DBMS. Its cheap, its
efficient, and I don't see why we shouldn't take advantage of the
technology. It is very different to run a pair of machines sitting in
closets than it is to run an InterNIC. We aren't talking a big
operation. I will not, however, support running stuff with perl
scripts, masking tape and chewing gum, either. That takes more work,
not less, and its more dangerous, not less dangerous.

Perry


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

Date: 20 Aug 1996 06:58:05 -0700
From: huitema@bellcore.com (Christian Huitema)
Subject: Centralized or decentralized Whois server ?

The whois service is very important -- how could we run any registration
service if we did not have a way to find out precisely who registered
what?
Thus, I certainly understand why we should make sure that the information
is available, and remains available even if one registry vanishes in a
puff of smoke.

Archiving everything in one mammoth database is one way to solve the
problem. However, that solution has drawbacks. It creates a central focal
point, which is arguably suboptimal in terms of performances, reliability
and also distribution of control. However, there are alternatives, notably
if we were to promote the "whois++" solution. Its use of centroids enables
"navigation without hierarchy", so that requests will be automatically
directed to whatever server holds the information.

Then, we would have to solve the puff of smoke problem. What about an
escrow database ?

- --
Christian Huitema


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

Date: 20 Aug 1996 07:59:32 -0700
From: johnl@iecc.com (John R Levine)
Subject: Re: New Non-Shared TLD's Create More Monopolies

>If the CDB contains all the authoritative data, then it is a very
>short step to a direct email interface, bypassing registries.
>Contracts can be developed that will avoid that, you're right.

No, wait, it's a very big step, because that step involves money.
I'm working under the assumption that registries have a contract with
the CDB, so they can use a straightforward billing scheme (so much per
domain per month, so much per transaction, something like that.)  One of
the things that makes the Internic so unwieldy is that they have a million
separate customers.  Shared registries spread this out somewhat.

>Hmm.  Your last clause means "there is good reason to operate a
>centralized database".  The only good reason I've seen so far is to
>support a reservation protocol on names, and for that you only need
>the names.  And even there, the "lazy propagation" character of DNS
>makes me think that locking methods using DNS itself might be sufficient.

Sigh.  You'd almost think there wasn't a long exchange of messages on this
topic only a week ago.  The other reason to have a CDB is to force the data
to be syntactically correct and consistent.  (It may not all be semantically
correct, but at least it'll be in one place so that corrections can be
applied.)  The only alternative I've seen proposed is some sort of big daily
merge of all the registries' separate data, and I think at the time we agreed
that it was unlikely that you'd be able to merge several hundred or thousand
sets of data without running into some consistency errors, requiring in
effect some central authority to sort it out anyway.


- --
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: 20 Aug 1996 08:30:12 -0700
From: Kent Crispin 
Subject: Re: New Non-Shared TLD's Create More Monopolies

David R. Conrad allegedly said:
>
> Alan,
>
> >Now, if several near-simultaneous attempts are made to reserve the name,
> >only one will succeed, and the losers know that they have lost *before* they
> >start setting up the nameservers.  So the losers have no work that needs to
> >be undone.
>
> Thanks for the clarification.  I'm interested in getting up and
> running as fast and reliably as possible, thus I was assuming that the
> CDB (which is what I guess we're calling it) would not do any of the
> checking to see if the nameservers were up.  As such, the race
> condition wouldn't exist.  The scenario I envisioned was:

All that is necessary to implement reservations is the following
simple mods to your algorithm:

> 1) person chooses name
> 2) person goes to registry to request name, providing registration data
> 3) registry requests name
> 4) if name exists,
  4a)	and timestamp is current
> , goto step 1
> 5) CDB allocates name
	with timestamp and registry id
> 6) person pays registry
  6a) registry sends confirm.
	if name is there with right regid
		build registration data at registry and build zone file
	else
		return "time expired"
> 7) person sets up DNS service
> 8) zone file distributed to appropriate servers
>
> Is adding the state, timers, and server complexity valuable enough to
> warrant the addition of the NS checking code (no opinion, just
> asking)?

It really just rearranges the steps slightly, and adds a timestamp to
the database.  Very little extra work or code or state information is
involved.  A mere 10 more minutes of perl hacking :-)

> Of course, the race condition can also be "avoided" by just saying,
> "sorry, name taken, remove the gunk from the primaries and
> secondaries", but I'd agree this would be annoying.


- --
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


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

Date: 20 Aug 1996 08:45:50 -0700
From: Kent Crispin 
Subject: Re: New Non-Shared TLD's Create More Monopolies

David R. Conrad allegedly said:
>
> >In other words we define an HTML form that uses POST
> >transactions and we define the behavior of the backend CGI script that
> >handles it.
>
> There are many places in the world that could concievably want to be
> registries under this scheme that have no hope of using the WWW (e.g.,
> they're on the end of a UUCP line).

Yes -- the cannonical "registry on Pitcairn Island".  Not being
facetious, really, there are many parts of the world where the net
infrastructure is very poor, but I don't want to name them for fear of
offending anyone.  Pitcairn Island just serves as a useful symbol.

I certainly have no objection to defining an HTML interface.  But
(IMO) a direct protocol is necessary, whereas an HTML interface is a
nice nicety.

- --
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


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

Date: 20 Aug 1996 09:17:28 -0700
From: Kent Crispin 
Subject: Re: New Non-Shared TLD's Create More Monopolies

Michael Dillon allegedly said:
>
> On Tue, 20 Aug 1996, David R. Conrad wrote:
>
> > >In other words we define an HTML form that uses POST
> > >transactions and we define the behavior of the backend CGI script that
> > >handles it.
> >
> > There are many places in the world that could concievably want to be
> > registries under this scheme that have no hope of using the WWW (e.g.,
> > they're on the end of a UUCP line).
>
> Once we have defined the fields used for a CGI POST transaction there is
> no reason why alternative interfaces cannot be devised.

Cart before Horse.

- --
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


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

Date: 20 Aug 1996 09:17:33 -0700
From: Kent Crispin 
Subject: Re: New Non-Shared TLD's Create More Monopolies

Simon Higgs allegedly said:
>
> At 9:43 PM -0700 8/19/96, Kent Crispin wrote:
>
> >I can accept (though grudgingly) that a centralized database for
> >synchronization is small enough and simple enough that it is unlikely
> >to become a serious problem.  However, when this central database
> >also becomes the authoritative repository for all the contact
> >information I begin to worry.
> >
>
> This is an issue for later on (transaction scalability), but don't forget
> Bob Frank's FOI request for the InterNIC database. There are numerous
> third-party uses for the information outside the snail-mail spamming like
> CRL and others do. Trademark searches are going to be done in any whois
> created. That includes both the matches for addresses as well as domain and
> organizational names. Several companies already tie up NSI's whois with
> bulk searches. Should these searches tie up each registry's whois or be
> assigned to a mirrored master whois database (or just be downloaded via
> ftp)?

Or should they be allowed at all?

Privacy issues are another argument for distribution, as far as I
am concerned.

- --
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


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

Date: 20 Aug 1996 09:48:25 -0700
From: Kent Crispin 
Subject: Re: New Non-Shared TLD's Create More Monopolies

Michael Dillon allegedly said:
>
> On Mon, 19 Aug 1996, Kent Crispin wrote:
>
> > > If you are suggesting that we build a pseudo-database interface on top of
> > > a text interface then I strongly disagree.
> >
> > Nope.  I'm suggesting a perl script that runs rwhois, gets the data,
> > and inserts all of it into a local whois database.
>
> Yuck!

You could write it in C++, or perhaps have a CGI interface, if you
like :-)

> > That would be nice, but I don't it is necessary for shared-tld to
> > mandate that particular change.  The whois format is the current
> > standard, apparently moving to rwhois, and, as Perry says, we should
> > only change one thing at a time. :-)
>
> Who says whois is a "standard"?

RFC942, I think.

> And who says that it is moving to rwhois?
> One thing I know for sure is that Netscape and just about every other OS
> and Internet tools vendor is adding support for LDAP queries into their
> products so when that is available, LDAP will be far more standard than
> rwhois.

See RFC1714.  I believe you mean "more widespread", not "more standard".

> Not that I have anything against rwhois, just that the writing is
> on the wall and we should encourage people to build a rational
> architecture that will work with the directory service that 95% of the
> Internet community will be using a year from now.

Perhaps we should specify NT as the OS, as well?

> > > One way to do this is to have a centralised database that anyone can
> > > replicate at will and use to serve local requests when the central nature
> > > of the database is not relevant.
> >
> > "Distributed" to me implies "distributed responsibility".
>
> You cannot distribute the responsibility to apply the first-come
> first-served rule.

Of course you can.

[snip]

> What is this monopolistic abuse problem?

Hypothetical:  IANA is charged with running the CDB.  5 years from
now a contract is let to a company, Network Savants, Inc., to manage
the CDB.  NSI (no relation to the current NSI) decides that a
subsidiary will go into the registry business...

> > I can accept (though grudgingly) that a centralized database for
> > synchronization is small enough and simple enough that it is unlikely 
> > to become a serious problem.  However, when this central database
> > also becomes the authoritative repository for all the contact
> > information I begin to worry.
>
> Why? If a registry agent wants to maintain their own customer contact
> database off to the side they are free to do so.

Let me rephrase that:  The agency maintaining the CDB can maintain
their own, non-authoratitive contact database if they want to.

> > of the advantage of moving as much responsibility as possible out to
> > the registries is that they become the primary source of legal
> > liability.  And the more a local person can blame their local registry
> > for screwups, the better.

[argument deleted]

I thought through this stuff a while back in my initial half-baked
suggestions for a voting protocol with unforgable timestamps.  I
agree that it is simpler to have a centralized interlock mechanism.
I don't agree that it is the only system that will work -- there are
tradeoffs, that's all.

> Might as well plan for the legal liabilities and have one single central
> database run by an organization chartered under Swiss law in Geneva that
> has some level of immunity from prosecution.

I would really prefer a technical solution that results in such strong
localized responsibility that any centralized part of the service is
essentially immune from legal action, because it has no authority.
To be more specific, a centralized mechanism (might not be anything
other than a small addition to DNS) that merely prevents name
choosing conflicts is vastly different in legal exposure than a
centralized database that contains all contact information for all
SLDs, that is searchable for trademark conflicts, and other clever
social engineering schemes.

- --
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


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

Date: 20 Aug 1996 10:32:55 -0700
From: Matthew James Marnell 
Subject: Re: Mandated shared registries

:>I give away SLDs for a year for free, so that I'm the only player. I
:>then start charging more for renewals, knowing that I've got
:>market momentum that can carry me much farther than anyone else
:>getting into the field anew. Additionally, I always have the
:>threat that I can go back to doing it for free if anyone becomes
:>a significant player.

A) it won't work, and B) it won't work.  I'm not saying that it
won't work from the viewpoint of your company not having enough
money to do it, I saying it won't work because, nobody would easily
be able to handle the flood of new domain registrations.  On a day
to day basis, you may very well be able to handle it, but in the
long run entropy creeps in.  The first time something happens between
you and your customer, like a section of sprint going down yesterday,
or any other small thing, and you start getting the least bit behind,
or loose a domain or 2, the "You get what you pay for." principle kicks
in and people begin to see that that registry over there, that does
registrations as a sideline of their main business, and charges $X
actually gives you more for your money.

The first post to USENET, inet-access and IAP about you and you've
got a rep.  The more posts, the worse the rep.  Pretty soon, people
who do registrations for clients, or as a sideline business are doing
just fine, and you're getting all the freeloaders, who wouldn't normally
pay if they had to.

Even when you do start to charge, you're not likely to have cornered
much of a "market" for yourself, neither have you done your business
much good, nor the industry as a whole, but it'll bounce back.

So, what you'll really get for your trouble, is more trouble.  I may
be misremembering the circumstances, but I think I remembered that you
had external backers who may actually know a bit about business.  Do
you think their going to be happy about loosing more money?  If I'm
wrong and you're flying it yourself, how long and how much money can
you afford to loose before the vultures come in to pick your bones.

:>I'm doing nothing of the sort. Perry, you're quite adept at throwing
:>around assumptive arguments and mudslinging, which only tarnishes
:>your occasional valid point. Please stop putting words into my mouth.

Can we see some words that actually reflect reality first.  One registry
charging nothing isn't a realistic arguement.  Look at the current
MSIE/NN wars and a million other examples.  Toyotas?  If ever there
was an example of bad analogies, that was it.  I could go on and on,
but won't.

Let us just quickly look at some quick and dirty examples of companies
that were given an artificial monopoly over a certain area, RBOCs.
I can't think of anyone that has been overly happy with their RBOC's
performance, nor can I think of many people who are displeased with
the opening up of competition in this area.  So, what we're really
looking at is the near impossible reversal of monopoly TLDs when it
turns out that, for the most part, not necessarily true of you, that
most people feel that it benefits nobody but the monopoly owner and
asks for the overthrow of the TLDOCs for more open competition.

Matt



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

Date: 20 Aug 1996 11:05:24 -0700
From: Simon Higgs 
Subject: [ADMIN] Test



_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...




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

Date: 20 Aug 1996 11:21:43 -0700
From: Kent Crispin 
Subject: Re: New Non-Shared TLD's Create More Monopolies

Perry E. Metzger allegedly said:
>
>
> Kent Crispin writes:
> > Nope.  I'm suggesting a perl script that runs rwhois, gets the data,
> > and inserts all of it into a local whois database.
>
> Having built crap like that before, I'll tell you that one's life is
> always much, much happier when you have a real database. Perl hacks
> from text taken off the net are for when you have no choice.

Or when you are doing a prototype.

> > I can accept (though grudgingly) that a centralized database for
> > synchronization is small enough and simple enough that it is unlikely 
> > to become a serious problem.  However, when this central database