-> Charter
by Kent Crispin
-> Re: New Non-Shared TLD's Create More Monopolies
by Kent Crispin
----------------------------------------------------------------------
Date: 18 Aug 1996 14:40:02 -0700
From: Kent Crispin
Subject: Re: New Non-Shared TLD's Create More Monopolies
John R Levine allegedly said (in a long reply to someone_:
> I also agree that neither of us is likely to change the other's mind, so I'd
> just as soon get along with designing some shared TLDs to see how well they
> work.
OK :-)
Recapping the evolution of your "lightweight registry" model to date,
it seems to me the current synthesis would be:
IANA licenses registries for shared TLDs. IANA is responsible for
managing the coordination database (CDB) for all shared TLDs. (It may
choose to do this inhouse or contract it to some other party, the
"lightweight registry". This activity would be supported by the
license fees.)
Regular registries (just "registries", from now on) communicate with
the CDB via a simple protocol, with perhaps the following 4 basic operations:
1) create/reserve(name) -- creates a shortlived entry for the name,
associates it with the registry. Returns an error if name is already
present.
2) confirm(name,IP) -- converts a temporary entry to a permanent one ...
"after the check clears", causes the name/IP to be bound together in DNS
3) lookup(name) -- returns the id (and IP) for the registry that
services name.
4) delete(name) -- removes the name, both from the CDB and DNS.
The protocol between the registry and the CDB requires strong
authentication. We have several tentative ideas kicking around on
this, but no firm proposals.
Also as yet unexplored is the relationship with DNS.
So it seems to me that we have three questions worth some extended
discussion:
1) Are these CDB operations appropriate?
2) How is authentication done?
3) How does get into DNS? And, which entity(ies) runs the
nameserver(s)?
There's a meta question that comes to my mind, as well:
4) How detailed do we need to get as far as protocol specifications?
Well?
- --
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: 18 Aug 1996 15:15:12 -0700
From: perry@piermont.com
Subject: Re: New Non-Shared TLD's Create More Monopolies
Kent Crispin writes:
> Regular registries (just "registries", from now on) communicate with
> the CDB via a simple protocol, with perhaps the following 4 basic operations:
Not sure that a "simple protocol" is the right idea. I suspect a
better idea is an authenticated database access protocol is the right
thing. However...
> 1) create/reserve(name) -- creates a shortlived entry for the name,
> associates it with the registry. Returns an error if name is already
> present.
Something like that.
> 2) confirm(name,IP) -- converts a temporary entry to a permanent one ...
> "after the check clears", causes the name/IP to be bound together in DNS
Er, what is this about binding names to IPs? Thats something you do
for an A record, not for a domain name.
> 3) lookup(name) -- returns the id (and IP) for the registry that
> services name.
Why should we care about some random IP address at the registry?
> 4) delete(name) -- removes the name, both from the CDB and DNS.
There is an implication here that we want two protocols, one that
interacts with the CDB and one that communicates with the root
servers. Dunno if thats wrong, its just an unstated implication.
In my opinion, your model isn't rich enough, and isn't fully
explored.
Better to start out by saying what sort of information is stored in
the CDB, what the access rights are for it, and what the life cycle of
that data is. Among other interesting questions:
1) Is anything ever truly "deleted", or just "inactivated"?
2) How do we encode the access rights a particular registry has with
respect to particular TLDs, and with respect to particular records
within a TLD?
3) What sort of reports are created off the CDB? (My guess: whois and
DNS primary files, but there may be others). What sort of data is
needed for these reports?
A good start would be a definition of the database in terms of the
tables that would be stored. Yes, this isn't protocol land yet, but it
is probably needed no matter what, and it may tell us something,
specifically, that the scope of operations we may want is broad
enough that a full database access protocol is more appropriate than a
specialized protocol.
> 3) How does get into DNS?
Again, that has nothing to do with the "CDB" -- there are plenty of
domain names in the world with no A records at all! The servers for
.COM or whatever only get NS records for the domains, and they have no
need for anything else.
> And, which entity(ies) runs the nameserver(s)?
The folks that run them now, probably.
> There's a meta question that comes to my mind, as well:
>
> 4) How detailed do we need to get as far as protocol specifications?
If we produce a protocol, it has to be detailed enough to permit an
independant implementation from the spec alone, as with all protocol
documents.
As I've said, though, a protocol is probably premature. We have to
start this with a database design.
Perry
----------------------------------------------------------------------
Date: 18 Aug 1996 16:57:12 -0700
From: Simon Higgs
Subject: Re: New Non-Shared TLD's Create More Monopolies
At 6:14 PM -0400 8/18/96, Perry E. Metzger wrote:
>Kent Crispin writes:
>> Regular registries (just "registries", from now on) communicate with
>> the CDB via a simple protocol, with perhaps the following 4 basic
>>operations:
>
>Not sure that a "simple protocol" is the right idea. I suspect a
>better idea is an authenticated database access protocol is the right
>thing. However...
>
>> 1) create/reserve(name) -- creates a shortlived entry for the name,
>> associates it with the registry. Returns an error if name is already
>> present.
>
>Something like that.
>
>> 2) confirm(name,IP) -- converts a temporary entry to a permanent one ...
>> "after the check clears", causes the name/IP to be bound together in DNS
>
>Er, what is this about binding names to IPs? Thats something you do
>for an A record, not for a domain name.
>
I think he means creating the zone NS record for the domain being
registered, and pointing that to the applicants name server.
>> 3) lookup(name) -- returns the id (and IP) for the registry that
>> services name.
>
>Why should we care about some random IP address at the registry?
>
>> 4) delete(name) -- removes the name, both from the CDB and DNS.
>
Inactivates name from CDB. Removes NS record from DNS. I'm not sure if
"delete" is the right term here.
>There is an implication here that we want two protocols, one that
>interacts with the CDB and one that communicates with the root
>servers. Dunno if thats wrong, its just an unstated implication.
>
Are we assuming that the TLDs are on different servers from the root (per
draft-manning)? The only time the root needs to be changed is when the NS
records are created/changed for each particular TLD. This won't happen very
often, and when it does, it will be under IANA's control. If the TLD
records are on seperate servers, the CDB will interact with these. I don't
see a need for the CDB to have access to the root.
>In my opinion, your model isn't rich enough, and isn't fully
>explored.
>
>Better to start out by saying what sort of information is stored in
>the CDB, what the access rights are for it, and what the life cycle of
>that data is. Among other interesting questions:
>
>1) Is anything ever truly "deleted", or just "inactivated"?
My vote is for inactivation. Having the history of a particular set of
records is important, if for no other reasons than legal ones.
>2) How do we encode the access rights a particular registry has with
> respect to particular TLDs, and with respect to particular records
> within a TLD?
>3) What sort of reports are created off the CDB? (My guess: whois and
> DNS primary files, but there may be others). What sort of data is
> needed for these reports?
>
>A good start would be a definition of the database in terms of the
>tables that would be stored. Yes, this isn't protocol land yet, but it
>is probably needed no matter what, and it may tell us something,
>specifically, that the scope of operations we may want is broad
>enough that a full database access protocol is more appropriate than a
>specialized protocol.
>
This is a very basic set which only contains current records, but it's a
start to work from:
Contact table:
Contact_ID
First_Name
Last_Name
Organization
Address
City
State
Postal_Code
Country
Telephone
Fax
Email
Authentication
Record_Created
Last_Modified
Domain table:
Domain_ID
Domain_Name
TLD
Purpose
Organization <-- linked to Contact table.Contact_ID
Administrative_Contact <-- linked to Contact table.Contact_ID
Technical_Contact <-- linked to Contact table.Contact_ID
Billing_Contact <-- linked to Contact table.Contact_ID
Primary_NS <-- linked to Host table.Host_ID
Secondary_NS <-- linked to Host table.Host_ID
Authentication
Record_Created
Last_Modified
Host table:
Host_ID
Host_IP
Host_Name
Host_Hardware
Host_Software
Authentication
Record_Created
Last_Modified
_____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: 18 Aug 1996 18:48:04 -0700
From: Kent Crispin
Subject: Re: New Non-Shared TLD's Create More Monopolies
Perry E. Metzger allegedly said:
>
>
> Kent Crispin writes:
> > Regular registries (just "registries", from now on) communicate with
> > the CDB via a simple protocol, with perhaps the following 4 basic operations:
>
> Not sure that a "simple protocol" is the right idea. I suspect a
> better idea is an authenticated database access protocol is the right
> thing. However...
Propose, propose, propose -- I'm just trying to get some discussion
going. But try to propose things I can understand :-)
> > 1) create/reserve(name) -- creates a shortlived entry for the name,
> > associates it with the registry. Returns an error if name is already
> > present.
>
> Something like that.
>
> > 2) confirm(name,IP) -- converts a temporary entry to a permanent one ...
> > "after the check clears", causes the name/IP to be bound together in DNS
>
> Er, what is this about binding names to IPs? Thats something you do
> for an A record, not for a domain name.
There I go again...
> > 3) lookup(name) -- returns the id (and IP) for the registry that
> > services name.
>
> Why should we care about some random IP address at the registry?
Because it is my impression that it is the registries that will keep
all the contact/whois data for the domain, not the CDB. The only
purpose for the CDB is to allow registries to coordinate, not to keep
all the data that the registry is supposed to keep.
>
> > 4) delete(name) -- removes the name, both from the CDB and DNS.
>
> There is an implication here that we want two protocols, one that
> interacts with the CDB and one that communicates with the root
> servers. Dunno if thats wrong, its just an unstated implication.
Yep.
> In my opinion, your model isn't rich enough, and isn't fully
> explored.
That's why I posted it, Perry. I have no attachment to the model. I
just want to get smart guys like you to contribute.
> Better to start out by saying what sort of information is stored in
> the CDB, what the access rights are for it, and what the life cycle of
> that data is. Among other interesting questions:
>
> 1) Is anything ever truly "deleted", or just "inactivated"?
You might keep historical records, but that's not the purpose of this
database. Since an "inactive" domain name could be reassigned to
another customer, at some point the historical information *will* be
lost, unless you keep it somewhere else.
> 2) How do we encode the access rights a particular registry has with
> respect to particular TLDs, and with respect to particular records
> within a TLD?
I don't have an answer, of course, but I do think it would be best to
proceed as if each TLD had a completely separate CDB -- so rather than
a single pentium machine handling all records for all TLDs, we could
have machine per TLD. Of course, this might only be a logical
separation, and the entire database might indeed be on one node. But
I would like to define it so that we didn't *require* a single node.
> 3) What sort of reports are created off the CDB? (My guess: whois and
> DNS primary files, but there may be others). What sort of data is
> needed for these reports?
I don't think the whois data should be in the CDB. The only thing
that needs to be in the CDB for a particular TLD is the SLD name, and
the identity of the registry that maintains that SLD's contact
information.
> A good start would be a definition of the database in terms of the
> tables that would be stored. Yes, this isn't protocol land yet, but it
> is probably needed no matter what, and it may tell us something,
> specifically, that the scope of operations we may want is broad
> enough that a full database access protocol is more appropriate than a
> specialized protocol.
There is only one table (per TLD) that needs to be stored: a table of
pairs. "name" is of course the SLD name, "registry" is a pointer to
the registry that serves that SLD.
> > 3) How does get into DNS?
>
> Again, that has nothing to do with the "CDB" -- there are plenty of
> domain names in the world with no A records at all! The servers for
> .COM or whatever only get NS records for the domains, and they have no
> need for anything else.
OK, but how do those *with* A/NS/etc records get into DNS?
> > And, which entity(ies) runs the nameserver(s)?
>
> The folks that run them now, probably.
That's fine for .com. But what nameservers would we contact for
.web, should it be created? I realize this is a "newdom" question,
but I think it would be good if our design didn't depend on just the
current set of nameservers.
> > There's a meta question that comes to my mind, as well:
> >
> > 4) How detailed do we need to get as far as protocol specifications?
>
> If we produce a protocol, it has to be detailed enough to permit an
> independant implementation from the spec alone, as with all protocol
> documents.
>
> As I've said, though, a protocol is probably premature. We have to
> start this with a database design.
OK -- just want to keep this moving along. However, it is my belief
that the CDB basically should be the extremely simple DB I described
above...
- --
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: 18 Aug 1996 19:02:16 -0700
From: Michael Dillon
Subject: Re: New Non-Shared TLD's Create More Monopolies
On Sun, 18 Aug 1996, Perry E. Metzger wrote:
> As I've said, though, a protocol is probably premature. We have to
> start this with a database design.
Right. But I'd go one step further and say that even a database design is
premature until we have a charter that is approved by the IETF and have a
real WG.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 18 Aug 1996 19:03:23 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: New Non-Shared TLD's Create More Monopolies
Just to sanity check you, the database items recently posted,
with the exception of the HINFO data (host hardware and software)
match *exactly* with our .WEB database design.
Christopher Ambler
----------------------------------------------------------------------
Date: 18 Aug 1996 20:33:13 -0700
From: perry@piermont.com
Subject: Re: New Non-Shared TLD's Create More Monopolies
Michael Dillon writes:
> On Sun, 18 Aug 1996, Perry E. Metzger wrote:
>
> > As I've said, though, a protocol is probably premature. We have to
> > start this with a database design.
>
> Right. But I'd go one step further and say that even a database design is
> premature until we have a charter that is approved by the IETF and have a
> real WG.
Michael;
Might I point out that you don't need to have a working group
completed before doing work? Hell, you can even submit an RFC for
proposed standard status without one.
We do have a proposed charter being tossed around and its getting
close, but we hardly need to have every "i" dotted and every "t"
crossed before starting to get some work done.
Perry
----------------------------------------------------------------------
Date: 18 Aug 1996 21:02:37 -0700
From: Michael Dillon
Subject: Re: New Non-Shared TLD's Create More Monopolies
On Sun, 18 Aug 1996, Perry E. Metzger wrote:
> We do have a proposed charter being tossed around and its getting
> close, but we hardly need to have every "i" dotted and every "t"
> crossed before starting to get some work done.
It does help to get the job done if you follow the charter though.
Anyway, let me rephrase my previous message. Yes I think it is necessary
to get the database design done before the protocol design, but I think it
is even more important to agree on a requirements document even if it is
not formally published.
You might say that all this is just meta-discussion but I would say that
we need to get the meta-discussion out of the way first, then agree on the
requirements for our design, then get down to details like database
layouts, transaction definitions and then one or more transaction
protocols.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 18 Aug 1996 22:29:09 -0700
From: chris@kosh.punk.net (Christopher Ambler)
Subject: Re: FW: New Non-Shared TLD's Break Monopolies (fwd)
Bob, your point is well made and well taken without having to resort
to profanity and name-calling. Dial it back a bit?
Christopher Ambler
President, Image Online Design, Inc.
----------------------------------------------------------------------
Date: 18 Aug 1996 23:07:24 -0700
From: Kent Crispin
Subject: Re: FW: New Non-Shared TLD's Break Monopolies (fwd)
Christopher Ambler allegedly said:
>
> Bob, your point is well made and well taken without having to resort
> to profanity and name-calling. Dial it back a bit?
Chris, because I consider your opinions seriously I actually went
back and undeleted Bobs letter (excesses stand out over anything
else, you're right about that) and read it through carefully.
However, I didn't find a well made point in it anywhere. Perhaps you
could translate?
- --
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: 18 Aug 1996 23:23:22 -0700
From: Kent Crispin
Subject: Charter
Michael Dillon allegedly said:
>
> On Sun, 18 Aug 1996, Perry E. Metzger wrote:
>
> > As I've said, though, a protocol is probably premature. We have to
> > start this with a database design.
>
> Right. But I'd go one step further and say that even a database design is
> premature until we have a charter that is approved by the IETF and have a
> real WG.
Michael, I have sent a copy of the draft charter to Scott Bradner, and
he replied that he was tied up with some other stuff for a bit, but he
would get back to me with a formal response as soon as he was free. I
don't want to mess around much with the charter until I hear from him
- -- he has a copy, and I don't want to tell him "oh what you have is
completely out of date -- we've changed everything around".
If I don't hear from him in a "reasonable" time I will pulse him
again.
Bottom line: The charter has reached a natural resting point for a
time. We could do as you suggest and sit on our thumbs, or we could
try to come to a better understanding of the issues. Personally I
prefer not to sit.
- --
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: 18 Aug 1996 23:44:05 -0700
From: Kent Crispin
Subject: Re: New Non-Shared TLD's Create More Monopolies
Simon Higgs allegedly said:
>
> At 6:14 PM -0400 8/18/96, Perry E. Metzger wrote:
>
> >Kent Crispin writes:
[snip]
> >> 2) confirm(name,IP) -- converts a temporary entry to a permanent one ...
> >> "after the check clears", causes the name/IP to be bound together in DNS
> >
> >Er, what is this about binding names to IPs? Thats something you do
> >for an A record, not for a domain name.
> >
>
> I think he means creating the zone NS record for the domain being
> registered, and pointing that to the applicants name server.
That's what I would have said if I hadn't had a brain fart. :-)
[snip]
> >1) Is anything ever truly "deleted", or just "inactivated"?
>
> My vote is for inactivation. Having the history of a particular set of
> records is important, if for no other reasons than legal ones.
This database is not a good one to keep this kind of history. When a
new owner gets an inactive name all the information will change and
the history will be lost. So it seems cleaner to me to just delete.
However, if it is understood that the historical information is not
authoritative, and that it is just kept around for things like
reinstatement of a previous owner, should he decide to renew, I
suppose it would be ok. But in that case I don't see any advantage
over creating a fresh record -- note that we would then require a
new operation "reinstate(name)".
> >2) How do we encode the access rights a particular registry has with
> > respect to particular TLDs, and with respect to particular records
> > within a TLD?
> >3) What sort of reports are created off the CDB? (My guess: whois and
> > DNS primary files, but there may be others). What sort of data is
> > needed for these reports?
> >
> >A good start would be a definition of the database in terms of the
> >tables that would be stored. Yes, this isn't protocol land yet, but it
> >is probably needed no matter what, and it may tell us something,
> >specifically, that the scope of operations we may want is broad
> >enough that a full database access protocol is more appropriate than a
> >specialized protocol.
> >
>
> This is a very basic set which only contains current records, but it's a
> start to work from:
[description of records deleted]
I really think this information should be kept at the registry, not
the CDB. If all this data is kept at the CDB, then everytime a tiny
change is made in the contact information the CDB gets involved. The
CDB thus handles all the "whois" queries. This seems to make the
"lightweight" registry actually rather heavy, and it becomes a general
service on the net, available to anyone who does a "whois" -- that is,
the CDB would become the "whois" server for the entire net, instead of
just a private database between the registries.
Ideally the DNS record for the domain should contain an enhanced DNS
record that contains the address of the registry that services that
domain. Whois queries would go directly to the registry that had the
data.
- --
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
