-> some definitions
by Kent Crispin
-> Re: How to handle first-come, first-served
by "Richard J. Sexton"
-> Re: How to handle first-come, first-served
by Dan Busarow
-> Re: How to handle first-come, first-served
by Michael Dillon
-> Re: How to handle first-come, first-served
by Kent Crispin
-> Re: How to handle first-come, first-served
by Kent Crispin
-> WG Charter
by Michael Dillon
-> Re: How to handle first-come, first-served
by Dan Busarow
-> Re: List purpose
by Keith Winstein
----------------------------------------------------------------------
Date: 28 Jul 1996 00:28:15 -0700
From: Simon Higgs
Subject: Re: List purpose
At 4:11 PM -0400 7/27/96, Richard J. Sexton wrote:
RE: Shared TLD List
>is this list the same as newdom? the charter looks different.
>
It is different. This list is a little more focused. It's mostly for
hashing out the logistics for establishing shared tld/registry databases
that didn't seem to be getting done on newdom. It's one step on from where
newdom left off, and takes a look at the situation from a different
perspective.
_____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: ________________ ______
..... .....
----------------------------------------------------------------------
Date: 28 Jul 1996 01:31:08 -0700
From: Simon Higgs
Subject: Re: How to handle first-come, first-served
At 11:23 PM -0700 7/27/96, Michael Dillon wrote:
>On Sat, 27 Jul 1996, Dan Busarow wrote:
>
>> Instead of reserving the name, just register it. Your customer must want
>> it, why else would you be checking?
>
>The theory is that I am a registry and I must execute a transaction
>against a shared database to register the name. In order to execute the
>registration I must have all the domain contact info, nameservers and a
>commitment from the customer. Sometime I want to check availability
>without collecting all the domain info or getting a commitment. If I
>cannot RESERVE the name then I cannot check availability because between
>the time I look and the time I get the customer committment someone else
>may already have registered the name in the SHARED database. This happens
>more and more frequently with the Internic and whois nowadays.
>
>Essentially, this reserve-then-register is a two-phase commit protocol.
>
Nope. ;-) You just answered your own question. Before you do a search, you
collect the customers info. You then have the customer in your database
which is a smart business move anyway. Then when you find an unregistered
domain, you can register it right then and there. If you don't have full
customer info, especially NS info, you have no right to reserve a name.
None whatsoever.
One phase. You're making it more complicated than it needs to be.
_____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: ________________ ______
..... .....
----------------------------------------------------------------------
Date: 28 Jul 1996 08:28:27 -0700
From: Kent Crispin
Subject: Re: How to handle first-come, first-served
Simon Higgs
>
> At 11:23 PM -0700 7/27/96, Michael Dillon wrote:
>
> >On Sat, 27 Jul 1996, Dan Busarow wrote:
> >
> >> Instead of reserving the name, just register it. Your customer must want
> >> it, why else would you be checking?
> >
> >The theory is that I am a registry and I must execute a transaction
> >against a shared database to register the name. In order to execute the
> >registration I must have all the domain contact info, nameservers and a
> >commitment from the customer. Sometime I want to check availability
> >without collecting all the domain info or getting a commitment. If I
> >cannot RESERVE the name then I cannot check availability because between
> >the time I look and the time I get the customer committment someone else
> >may already have registered the name in the SHARED database. This happens
> >more and more frequently with the Internic and whois nowadays.
> >
> >Essentially, this reserve-then-register is a two-phase commit protocol.
> >
>
> Nope. ;-) You just answered your own question. Before you do a search, you
> collect the customers info. You then have the customer in your database
> which is a smart business move anyway. Then when you find an unregistered
> domain,
Find an unregistered domain in which database? Remember a
distributed database is split into many components, and you can't
search them all simultaneously. Michael is exactly right -- you need
some way to do an atomic transaction in a distributed database
(two-phase commit is one standard algorithm for doing that.
> you can register it right then and there.
You can't just register it, because your counterpart in Africa may be
registering the exact same domain name at the exact same time.
> If you don't have full
> customer info, especially NS info, you have no right to reserve a name.
> None whatsoever.
>
> One phase. You're making it more complicated than it needs to be.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 28 Jul 1996 08:38:02 -0700
From: Kent Crispin
Subject: some definitions
Here's an attempt at a set of definitions. I wanted to be able to
make a distinction between registries and nameservers, so thought I
would propose the following. Note that I don't have any attachement
to this particular terminology -- I just think we should be able to
make these distinctions without forever having to reexplain ourselves
:-)
Description of a Domain Name Registry
A Domain Name Registry is an entity that serves as an
intermediary between the DNS and other named entities, such as
individual humans, corporations, universities, and so on.
These entities are termed "Clients". A DNR maintains a Client
Database (CDB) of these entities, searchable through the
"whois" protocol. A DNR communicates with other DNRs via the
InterRegistry Protocol (IRP), and communicates with the root
name servers via a yet to be defined protocol (possibly
involving human interaction).
A DNR provides a basic service to Clients: It registers
a Domain Name in DNS for that Client. This basic service
requires that the DNR maintain records of the Client in a
whois database. [There are complex issues of identity and
privacy involved here. The primary concern is that there
be some "real" entity behind every domain name, and that
the domain name is not "wasted" -- there should be some
criteria for bona fide use of a domain name.]
Note that the role of a registry is distinct from the role of
a nameserver -- the nameserver maintains the association
between a Domain Name and an IP address, while a registry
maintains the association between Clients and Domain Names.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 28 Jul 1996 09:28:34 -0700
From: "Richard J. Sexton"
Subject: Re: How to handle first-come, first-served
(Simon, can you make the reply-to addres the list, not the sender ?)
> You can't just register it, because your counterpart in Africa may be
> registering the exact same domain name at the exact same time.
And whichever registration request hits the nic first, wins.
Thisis the situaiton now, is it not ?
The down side to this is *much* less than the downside
to "here, hold this name for me". If you were trying to design
a system meant for abuse, this would be the way to do it.
----------------------------------------------------------------------
Date: 28 Jul 1996 12:05:21 -0700
From: Dan Busarow
Subject: Re: How to handle first-come, first-served
On Sun, 28 Jul 1996, Richard J. Sexton wrote:
> > You can't just register it, because your counterpart in Africa may be
> > registering the exact same domain name at the exact same time.
>
> And whichever registration request hits the nic first, wins.
Exactly. You don't even need to check the name's availability ahead of
time. Fill out your form with the requested name, submit the info, you
get back a confirmation or a denial. If you get back a denial, change
one field on the form by entering a second or third or fourth choice and
resubmit.
Unless your registry will be providing services currently associated with
ISPs (like _primary_ nameservice) most of your _direct_ customers will be
ISPs. They will have checked the name, they will have counseled _their
customer that it may disappear any moment and get the 2nd etc.. choices.
Dan
- --
Dan Busarow 714 443 4172
DPC Systems dan@dpcsys.com
Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82
----------------------------------------------------------------------
Date: 28 Jul 1996 12:53:05 -0700
From: Michael Dillon
Subject: Re: How to handle first-come, first-served
On Sun, 28 Jul 1996, Dan Busarow wrote:
> Unless your registry will be providing services currently associated with
> ISPs (like _primary_ nameservice) most of your _direct_ customers will be
> ISPs. They will have checked the name, they will have counseled _their
> customer that it may disappear any moment and get the 2nd etc.. choices.
You are talking about greatly limiting the type of customers a registry
can deal with as well as limiting the quality of service that they can
supply to their customers. There is no way I can agree with this.
We should be building a system that meets the needs of all Internet users,
not just some technical jockeys who want to sysadmin a registry machine.
Which reminds me, what about a charter for an IETF WG?
Are we going to go off in left field and try to define this stuff on our
own? Or are we going to work it within the system?
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 28 Jul 1996 13:04:04 -0700
From: Kent Crispin
Subject: Re: How to handle first-come, first-served
Richard J. Sexton
>
> > You can't just register it, because your counterpart in Africa may be
> > registering the exact same domain name at the exact same time.
>
> And whichever registration request hits the nic first, wins.
You are missing the point of shared TLDs, I think. The guy in Africa
and you *are* the nic (along with perhaps hundreds of others). With
shared TLDs there is no single "nic" that receives a request -- the
nic *itself* is a distributed database, and different parts of it can
receive requests for the same domain name, but from different
registries. The real problem that must be solved is how to manage the
distributed nic.
The software technology to do this kind of stuff is straightforward,
but it is definitely not trivial.
> Thisis the situaiton now, is it not ?
>
> The down side to this is *much* less than the downside
> to "here, hold this name for me". If you were trying to design
> a system meant for abuse, this would be the way to do it.
>
The "reservations" that are being discussed are database management
level reservations, not high level reservations, and typically would
have short lifetimes.
Here's a completely inadequate outline for a protocol, that uses
unforgable certified timestamps (the problem of creating unforgable
timestamps is left for an exercise :-):
Assume a large community of nameservers that comprise the primary
nameserver *set* for a given TLD.
All these nameservers are peers; there is no master. (To allow
competition we don't want any one of them to be the master because
then the owner of the master could claim control, which would
essentially give us a single owner again.)
Each of the nameservers is required to keep an up-to-date copy of the
total database of SLDs. This is the tricky requirement to meet -- an
update of the database has to be acomplished across the whole set of
nameservers in an atomic fashion.
A request for a new SLD would proceed something as follows: First,
send a NAME-RESERVATION request to each of the nameservers, specifying
the desired name, and the ip address. Each nameserver will reply with
either a NAME-RESERVATION-ACK, with a certified timestamp, or a
NAME-RESERVATION-NAK, with a certified timestamp. The NAK implies
that someone else has made a reservation prior to yours.
After you have collected all the replies, either you will have more
ACKs than NAKs, or you won't. If you have the majority, then you send
the whole list back to each of the nameservers in a NAME-CREATE
request, with the certified timestamps, and claim the domainname. The
nameservers will verify the list, create the domainname, and assign it
to the ip address you specified. The registry that gets the minority
of certificates will have to report failure to the client, because
someone else got the name first.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 28 Jul 1996 13:09:42 -0700
From: Kent Crispin
Subject: Re: How to handle first-come, first-served
Michael Dillon
>
> On Sun, 28 Jul 1996, Dan Busarow wrote:
>
> > Unless your registry will be providing services currently associated with
> > ISPs (like _primary_ nameservice) most of your _direct_ customers will be
> > ISPs. They will have checked the name, they will have counseled _their
> > customer that it may disappear any moment and get the 2nd etc.. choices.
>
> You are talking about greatly limiting the type of customers a registry
> can deal with as well as limiting the quality of service that they can
> supply to their customers. There is no way I can agree with this.
>
> We should be building a system that meets the needs of all Internet users,
> not just some technical jockeys who want to sysadmin a registry machine.
>
> Which reminds me, what about a charter for an IETF WG?
> Are we going to go off in left field and try to define this stuff on our
> own? Or are we going to work it within the system?
Do you even have to ask? :-) I am 100% in favor of going the IETF route.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 28 Jul 1996 13:45:52 -0700
From: Michael Dillon
Subject: WG Charter
On Sun, 28 Jul 1996, Kent Crispin wrote:
> > Which reminds me, what about a charter for an IETF WG?
> > Are we going to go off in left field and try to define this stuff on our
> > own? Or are we going to work it within the system?
>
> Do you even have to ask? :-) I am 100% in favor of going the IETF route.
Yes, I do have to ask. The welcome message I got when subscribing talked
about a charter but so far many people want to dive right into specifying
protocol details and writing code when we don't even have the requirements
agreed upon yet.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 28 Jul 1996 14:38:22 -0700
From: Dan Busarow
Subject: Re: How to handle first-come, first-served
On Sun, 28 Jul 1996, Michael Dillon wrote:
> On Sun, 28 Jul 1996, Dan Busarow wrote:
> > Unless your registry will be providing services currently associated with
> > ISPs (like _primary_ nameservice) most of your _direct_ customers will be
> > ISPs. They will have checked the name, they will have counseled _their
> > customer that it may disappear any moment and get the 2nd etc.. choices.
>
> You are talking about greatly limiting the type of customers a registry
> can deal with as well as limiting the quality of service that they can
> supply to their customers.
That's not my intention. But unless you are registering names simply to
register them (the client has no intention of actually using it for
anything) you are going to need name servers. There are lots of
businesses out there who can and do run their own name servers so they
could certainly deal directly with a registry. But if you're registering
a name for Joe Sixpack and he really wants his e-mail to be deliverable
and his home page visible, you're going to need
1) his ISP's name servers' IP addresses and confidence that his ISP
says this is OK (and that the IP addresses are correct)
or
2) you (the registry) provide primary name service
The problem I see with #2 is maintenance. Every time Joe switches
providers you are going to need to update his zone. With the LD and cable
companies coming in and local competition for IP dial tone high, I would
think that this could become somewhat of a burden. Remember that Joe is
used to switching LD carriers without even having to know his own phone number.
So from a pragmatic point of view, I don't see registries dealing with the
general public unless they are also that public's ISP. (and I have no
problem with that, it's simply a degenerate case of dealing primarilly
with ISPs)
> Which reminds me, what about a charter for an IETF WG?
> Are we going to go off in left field and try to define this stuff on our
> own? Or are we going to work it within the system?
I'd like to see a WG.
Dan
- --
Dan Busarow 714 443 4172
DPC Systems dan@dpcsys.com
Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82
----------------------------------------------------------------------
Date: 28 Jul 1996 21:15:17 -0700
From: Keith Winstein
Subject: Re: List purpose
On Sat, 27 Jul 1996, Shared Top Level Domain Mailing List wrote:
> is this list the same as newdom?
>
> the charter looks different.
>
> do we want a replacement newdom ?
>
Ack! A misconfigured list! Argh... without signatures, it's now
impossible to tell who wrote this message. Simon, _please_ have the
"From:" header be the name of the sender of the message, and the
"Reply-to:" header be shared-tld@higgs.net. Please. :-)
