-> List purpose
by Simon Higgs
-> Re: List purpose
by chris@kosh.punk.net (Christopher Ambler)
-> Re: List purpose
by "Richard J. Sexton"
-> How to handle first-come, first-served
by Michael Dillon
-> Re: How to handle first-come, first-served
by Simon Higgs
-> Re: How to handle first-come, first-served
by Michael Dillon
-> Re: How to handle first-come, first-served
by chris@kosh.punk.net (Christopher Ambler)
-> Re: How to handle first-come, first-served
by Dan Busarow
-> Re: How to handle first-come, first-served
by John Leslie
-> Re: How to handle first-come, first-served
by John Leslie
-> Re: How to handle first-come, first-served
by "Richard J. Sexton"
-> Re: How to handle first-come, first-served
by Simon Higgs
-> Re: How to handle first-come, first-served
by woods@mail.weird.com (Greg A. Woods)
-> Re: How to handle first-come, first-served
by Simon Higgs
-> Re: How to handle first-come, first-served
by woods@mail.weird.com (Greg A. Woods)
-> Re: List purpose
by Eugene Kashpureff
-> Re: How to handle first-come, first-served
by Michael Dillon
-> Re: How to handle first-come, first-served
by Michael Dillon
----------------------------------------------------------------------
Date: 27 Jul 1996 12:52:42 -0700
From: Simon Higgs
Subject: List purpose
Welcome to the Shared Top Level Domain Mailing List. It's purpose is to
discuss the technical and logistical requirements of creating shared domain
name registration databases, and the administration of delegated top level
domains by multiple domain name registries.
This list is open to all with an interest in developing shared domain name
registration services. The intended function of this list is to be the
official home of an IETF working group.
Posting to this list is limited to subscribers only. Anyone can subscribe
to the list. This is mainly to prevent unwanted spamming and other
undesirable messages diluting the quality of the list.
Thanks to all of you for showing up.
This text can be found at .
_____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: 27 Jul 1996 13:05:33 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: List purpose
Question for you, Simon - if you intend for this list to be for
creating a working group, what becomes of those of us who belive
that shared TLDs are not a good idea, or, at best, not the ONLY idea?
Is there room for disagreement on the basic idea of sharing?
Chrisopher Ambler
----------------------------------------------------------------------
Date: 27 Jul 1996 13:10:52 -0700
From: "Richard J. Sexton"
Subject: Re: List purpose
is this list the same as newdom?
the charter looks different.
do we want a replacement newdom ?
----------------------------------------------------------------------
Date: 27 Jul 1996 14:18:41 -0700
From: Michael Dillon
Subject: How to handle first-come, first-served
I'm not sure if there is a WG charter in progress here or not but I'd like
to suggest that we divide up the sharing protocol two different ways.
First, I think that we need to have a reservation window so that a
registry can reserve a name, then tell the customer it is available and
reserved, then accept the order for the domain and then complete the
registration. So the FC/FS will be enforced by the procedure of reserving
a name.
Second, I think that we should specify two different stages of
implementation of the sharing/reservation protocol. Stage one should
specify that everything is done via a CGI script and all the record
locking is handled internally on a single master server. Later on we can
specify a more complex distributed reservation protocol that works with
distributed database servers that replicate each other.
So, the first protocol to specify would basically define the POST mode URL
for reserving a name and the POST mode URL for registering a name as well
as the form of the reply from the HTTP server so it can be machine parsed.
This allows us to get the database servers up quickly and cheaply with a
minimum of programming and debugging. It also allows the people running
the TLD database to use their choice of commercial RDBMS software or
freeware implementations. We might want to go so far as to specify Apache
with FastCGI (http://www.fastcgi.com) to ensure that the system will scale
with increased load.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 27 Jul 1996 16:23:31 -0700
From: Simon Higgs
Subject: Re: How to handle first-come, first-served
At 2:13 PM -0700 7/27/96, Michael Dillon wrote:
>First, I think that we need to have a reservation window so that a
>registry can reserve a name, then tell the customer it is available and
>reserved, then accept the order for the domain and then complete the
>registration. So the FC/FS will be enforced by the procedure of reserving
>a name.
>
The reservation should remain open until it is filled. It'd be too easy to
lock up hundreds of domains. What's to prevent a customer's competitor from
reserving their domain names? Right now, whois says whether it's available
or not. If the customer's data is entered first (with the NS info), the
time between knowing a domain is available and sending in a registration
could be just seconds.
Just as a comparison, does anyone know the procedure for reserving (800)
numbers?
>Second, I think that we should specify two different stages of
>implementation of the sharing/reservation protocol. Stage one should
>specify that everything is done via a CGI script and all the record
>locking is handled internally on a single master server. Later on we can
>specify a more complex distributed reservation protocol that works with
>distributed database servers that replicate each other.
>
I have no problem with the concept, but we're back to the question of who
provides the master database? It's got to be a neutral or authorative party
(IANA?).
>So, the first protocol to specify would basically define the POST mode URL
>for reserving a name and the POST mode URL for registering a name as well
>as the form of the reply from the HTTP server so it can be machine parsed.
>This allows us to get the database servers up quickly and cheaply with a
>minimum of programming and debugging. It also allows the people running
>the TLD database to use their choice of commercial RDBMS software or
>freeware implementations. We might want to go so far as to specify Apache
>with FastCGI (http://www.fastcgi.com) to ensure that the system will scale
>with increased load.
>
What about email? How much of the code used by InterNIC is readily available?
_____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: 27 Jul 1996 17:22:41 -0700
From: Michael Dillon
Subject: Re: How to handle first-come, first-served
On Sat, 27 Jul 1996, Simon Higgs wrote:
> >First, I think that we need to have a reservation window so that a
> >registry can reserve a name, then tell the customer it is available and
> >reserved, then accept the order for the domain and then complete the
> >registration. So the FC/FS will be enforced by the procedure of reserving
> >a name.
> The reservation should remain open until it is filled. It'd be too easy to
> lock up hundreds of domains. What's to prevent a customer's competitor from
> reserving their domain names?
A combination of publicity and timeouts. It may be sufficient to time out
the reservation after say, 6 hours, but a public list of reservation
activity on a website would help too.
> Right now, whois says whether it's available
> or not. If the customer's data is entered first (with the NS info), the
> time between knowing a domain is available and sending in a registration
> could be just seconds.
Then the timeout could be set to something like a few minutes. The idea is
that to provide customer service as follows:
Cust: I'd like to register a domain.
Reg: OK, would you like me to verify that the domain name is
available while you are on the phone?
Cust: Yeah, that'd be great! It's glooskap.web that I want.
Reg(typing into a WWW form): How do you spell that?
Cust: G-L-O-O-S-K-A-P.web
Reg: OK, got that. Hang on a second ......... Yep it's available and
reserved for you as long as we complete the registration
within the next hour.
Cust: Great, here's my Mastercard number.
To do this you need a reservation step to account for the time it takes to
collect all the info from the customer. And you really should have a long
enough timeout that if there is a network hiccup after the reservation but
before the registration, the registry can phone or fax the database
managers and complete the registration out-of-band.
> I have no problem with the concept, but we're back to the question of who
> provides the master database? It's got to be a neutral or authorative party
> (IANA?).
Maybe somebody should start emailling all the ISP's in Switzerland or
something...
> What about email? How much of the code used by InterNIC is readily available?
With their reputation I wouldn't want to touch that with a ten foot pole.
If we are going to do email regs, a similar form with colon headers and a
version number is a good idea though.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 27 Jul 1996 17:37:45 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: How to handle first-come, first-served
>Then the timeout could be set to something like a few minutes. The idea is
>that to provide customer service as follows:
>
>Cust: I'd like to register a domain.
>
>Reg: OK, would you like me to verify that the domain name is
> available while you are on the phone?
>
>Cust: Yeah, that'd be great! It's glooskap.web that I want.
>
>Reg(typing into a WWW form): How do you spell that?
>
>Cust: G-L-O-O-S-K-A-P.web
>
>Reg: OK, got that. Hang on a second ......... Yep it's available and
> reserved for you as long as we complete the registration
> within the next hour.
>
>Cust: Great, here's my Mastercard number.
Ironic, as for .WEB, we have that capability in place right now :-)
The question becomes one of automated registrations - once the customer
has access to the same lookup that the telephone-rep has, they can do
the check themselves. If they want it, how do they reserve it if they
wish to be invoiced or some other payment plan?
Christopher Ambler
President, Image Online Design, Inc.
----------------------------------------------------------------------
Date: 27 Jul 1996 17:49:11 -0700
From: Dan Busarow
Subject: Re: How to handle first-come, first-served
On Sat, 27 Jul 1996, Simon Higgs wrote:
> At 2:13 PM -0700 7/27/96, Michael Dillon wrote:
> >First, I think that we need to have a reservation window so that a
> >registry can reserve a name, then tell the customer it is available and
> >reserved, then accept the order for the domain and then complete the
> >registration.
Just signed on to the list so excuse me if I've missed something.
Instead of reserving the name, just register it. Your customer must want
it, why else would you be checking?
> What about email?
My feeling is that e-mail *has* to be supported. A web form with as many
fields as a domain registration has is just asking for problems. We
submit registrations from a template that has everything filled out except
for the customer info. Cuts way done on stupid mistakes.
And I just realized that as long as the web form is stable, you could run
a local, customized version of the form pointing at the database CGI. So
I guess it's not *that* important to have e-mail.
> How much of the code used by InterNIC is readily available?
I would guess none, since they started automating the process after
the NSF funding was stopped.
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: 27 Jul 1996 19:42:15 -0700
From: John Leslie
Subject: Re: How to handle first-come, first-served
Michael Dillon wrote:
>
> First, I think that we need to have a reservation window so that a
> registry can reserve a name, then tell the customer it is available and
> reserved, then accept the order for the domain and then complete the
> registration.
This is not strictly necessary. The registry could register the name
to itself for a brief period, and follow that with an update to the actual
customer -- or release the name if the registration isn't completed within
a reasonable time.
Either way, of course, we need to reach consensus about guidlines as
to how long a registry may hold a name in reserve.
I would prefer not to define a reservation window where the central
server has responsibility for expiring the reservation. This is contrary
to the spirit of TCP/IP, where the protocol imposes no timeouts. (It's
also more work for the central server.)
> Second, I think that we should specify two different stages of
> implementation of the sharing/reservation protocol. Stage one should
> specify that everything is done via a CGI script and all the record
> locking is handled internally on a single master server.
We're going to have to talk about a "master server" a lot. Can we
reach quick agreement on what to call it?
> Later on we can specify a more complex distributed reservation protocol
> that works with distributed database servers that replicate each other.
I agree that we're going to bog down a lot if we try to define a
distributed database at the outset.
> So, the first protocol to specify would basically define the POST mode URL
> for reserving a name and the POST mode URL for registering a name as well
> as the form of the reply from the HTTP server so it can be machine parsed.
I certainly hope that registries set up Web-based forms for the users
who wish to register a Second-Level-Domain; but I don't think it's a good
idea to make a similar interface between the registries and the master
server. The registries should be responsible for validity checking, and
pass the information to the master server well digested.
In maintaining xxx.xx.US domains, we've reached informal consensus
to pass things along ready to be pasted into our named (DNS daemon)
initialization files. At first blush, this seems to be a good format
for passing the critical information to the master server.
We should, of course, try to reach consensus on what that "critical
information" is. I'd recommend keeping it pretty minimal...
- --
John Leslie
----------------------------------------------------------------------
Date: 27 Jul 1996 20:06:33 -0700
From: John Leslie
Subject: Re: How to handle first-come, first-served
Simon Higgs wrote:
> Michael Dillon wrote:
>
>> Second, I think that we should specify two different stages of
>> implementation of the sharing/reservation protocol...
>
> I have no problem with the concept, but we're back to the question of
> who provides the master database? It's got to be a neutral or
> authoritative party (IANA?).
I vote for neutral.
The master server needn't do much except record which registry asked
first. Just make it a separate corporation which depends upon fee-for-
service income from the registries, ineligible to register anything by
itself.
- --
John Leslie
----------------------------------------------------------------------
Date: 27 Jul 1996 20:47:39 -0700
From: "Richard J. Sexton"
Subject: Re: How to handle first-come, first-served
> Michael Dillon wrote:
> >
> > First, I think that we need to have a reservation window so that a
> > registry can reserve a name, then tell the customer it is available and
> > reserved, then accept the order for the domain and then complete the
> > registration.
>
> This is not strictly necessary. The registry could register the name
> to itself for a brief period, and follow that with an update to the actual
> customer -- or release the name if the registration isn't completed within
> a reasonable time.
IMHO, this is barking down a trail that overly complex and
not required. How much of a problem is this *now*. You do
a whois, see the name is free, send of the form and you
get the name. Lets move one step at a time, first come
first nameserved.
> Either way, of course, we need to reach consensus about guidlines as
> to how long a registry may hold a name in reserve.
>
> I would prefer not to define a reservation window where the central
> server has responsibility for expiring the reservation. This is contrary
> to the spirit of TCP/IP, where the protocol imposes no timeouts. (It's
> also more work for the central server.)
Bleh.
>
> > Second, I think that we should specify two different stages of
> > implementation of the sharing/reservation protocol. Stage one should
> > specify that everything is done via a CGI script and all the record
> > locking is handled internally on a single master server.
>
> We're going to have to talk about a "master server" a lot. Can we
> reach quick agreement on what to call it?
How bout "the NIC".
> > Later on we can specify a more complex distributed reservation protocol
> > that works with distributed database servers that replicate each other.
>
> I agree that we're going to bog down a lot if we try to define a
> distributed database at the outset.
Uh, yeah. Look, the nic database right now is a sql database, we have
the record layouts, most of us gave webforms to interface with it
already. We have a couple of choices:
use current webforms to translate user info into an email (my
http://register.mydomain.com translates a template based on
the version 1 short form into a version 2 form which is emailed)
OR we can just have the cgi shoot off a sql query directly
to the NIC. I see no reson why we can't interrogate and update
the NIC database in realtime if we are regsistries.
>
> > So, the first protocol to specify would basically define the POST mode URL
> > for reserving a name and the POST mode URL for registering a name as well
> > as the form of the reply from the HTTP server so it can be machine parsed.
>
> I certainly hope that registries set up Web-based forms for the users
> who wish to register a Second-Level-Domain; but I don't think it's a good
> idea to make a similar interface between the registries and the master
> server. The registries should be responsible for validity checking, and
> pass the information to the master server well digested.
Validity checking can be done on either or both ends. You want to
use mail to do the registry/nic dataflow? Bleh.
> In maintaining xxx.xx.US domains, we've reached informal consensus
> to pass things along ready to be pasted into our named (DNS daemon)
> initialization files. At first blush, this seems to be a good format
> for passing the critical information to the master server.
>
> We should, of course, try to reach consensus on what that "critical
> information" is. I'd recommend keeping it pretty minimal...
The version 2 template ?
----------------------------------------------------------------------
Date: 27 Jul 1996 20:57:36 -0700
From: Simon Higgs
Subject: Re: How to handle first-come, first-served
At 5:37 PM -0700 7/27/96, Christopher Ambler wrote:
>The question becomes one of automated registrations - once the customer
>has access to the same lookup that the telephone-rep has, they can do
>the check themselves. If they want it, how do they reserve it if they
>wish to be invoiced or some other payment plan?
>
That's easy. Like now, they will only have access to domain name
availability from an assigned registry's whois. It's one step from there to
applying to that registry for the domain.
Reservations aren't really the issue. Ensuring everybody sees the same
information is.
_____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: 27 Jul 1996 21:04:06 -0700
From: woods@mail.weird.com (Greg A. Woods)
Subject: Re: How to handle first-come, first-served
[ On Sat, July 27, 1996 at 22:41:05 (-0400), John Leslie wrote: ]
> Subject: Re: How to handle first-come, first-served
>
> I would prefer not to define a reservation window where the central
> server has responsibility for expiring the reservation. This is contrary
> to the spirit of TCP/IP, where the protocol imposes no timeouts. (It's
> also more work for the central server.)
What if there is no "central" registry server? Why don't we design
something that'll work on a distributed basis? This is the Internet,
after all, and a distributed database is no longer "rocket science".
I think everyone who wants to talk about the low level technical details
should first get up to date on the available technology before we go off
half cocked and design some monstrosity out of the 1960's.
I myself am not by any stretch an expert in this field, but I do know
that it should be relatively simple to define a safe distributed
scalable transaction based protocol and API that would allow all
participants to manage a logically single global shared registry
database. Remember it doesn't really have to be real-time. A
transaction that adds a new zone and takes as much as an hour to
complete shouldn't be too terribly out of line. Modifications and such
can appear instantly and be replicated in the background.
However, maybe we can short-circuit all the low-level stuff:
I also know that there are freely available implementations of object
oriented distributed databases that might serve as a suitable base for
an implementation of a shared registry database. If this is indeed true
we should think of adopting their API and protocol, then think about
interfaces such as whois and rwhois, HTTP forms, e-mail forms, etc. as
well as some way to fit into building DNS zone files, data validation
and verification, etc.
Does anyone have experience with any existing technology that might be
suitable? Does anyone have time to evaluate any of the appropriate
distributed databases mentioned in the free-dbms FAQ:
ftp://ftp.idiom.com/pub/free-databases
http://cuiwww.unige.ch/~scg/FreeDB/
- --
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. ; Secrets of the Weird
----------------------------------------------------------------------
Date: 27 Jul 1996 21:09:14 -0700
From: Simon Higgs
Subject: Re: How to handle first-come, first-served
At 11:05 PM -0400 7/27/96, John Leslie wrote:
>>> Second, I think that we should specify two different stages of
>>> implementation of the sharing/reservation protocol...
>>
>> I have no problem with the concept, but we're back to the question of
>> who provides the master database? It's got to be a neutral or
>> authoritative party (IANA?).
>
> I vote for neutral.
>
> The master server needn't do much except record which registry asked
>first. Just make it a separate corporation which depends upon fee-for-
>service income from the registries, ineligible to register anything by
>itself.
>
Jon,
Does this fit in with your next draft?
_____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: 27 Jul 1996 21:13:47 -0700
From: woods@mail.weird.com (Greg A. Woods)
Subject: Re: How to handle first-come, first-served
[ On Sat, July 27, 1996 at 20:56:29 (-0700), Simon Higgs wrote: ]
> Subject: Re: How to handle first-come, first-served
>
> Reservations aren't really the issue. Ensuring everybody sees the same
> information is.
Absolutely!
- --
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. ; Secrets of the Weird
----------------------------------------------------------------------
Date: 27 Jul 1996 22:42:11 -0700
From: Eugene Kashpureff
Subject: Re: List purpose
So...as of yet there is no code to run a shared registry .
We all know it's possible, but if you hang on guard-tslk@internic,
then you know what a charlie-fox the InterNICs current non-shared
registry is right now ... and some entity is gonna do the same
for shared registries ?
At your name service,
Eugene Kashpureff, ALTERNIC.NET
----------------------------------------------------------------------
Date: 27 Jul 1996 23:28:39 -0700
From: Michael Dillon
Subject: Re: How to handle first-come, first-served
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.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 27 Jul 1996 23:45:08 -0700
From: Michael Dillon
Subject: Re: How to handle first-come, first-served
On Sun, 28 Jul 1996, Greg A. Woods wrote:
> I think everyone who wants to talk about the low level technical details
> should first get up to date on the available technology before we go off
> half cocked and design some monstrosity out of the 1960's.
This is not about fads and fashions. This is about deciding what features
are needed in the system and then applying the appropriate tools and
technology needed for implementation. If a 1960's technology like GNU gdbm
fills the bill, then so be it.
But we won't know for sure until we get our requirements straight, and
design the protocol. If we end up having one single global master server
then it makes sense to just buy an RDBMS like ORACLE or PROGRESS. But we
can't make taht decision until we have an outline of what we need.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
