-> Charter
by Kent Crispin
-> Re: Charter
by "Richard J. Sexton"
-> Re: .com
by Kent Crispin
-> Re: .com
by Michael Dillon
-> Re: .com
by Kent Crispin
-> Re: Charter
by Kent Crispin
-> Lightweight vs. heavyweight registries
by johnl@iecc.com (John R Levine)
----------------------------------------------------------------------
Date: 1 Aug 1996 00:07:03 -0700
From: Kent Crispin
Subject: Charter
Michael Dillon
>
> On Wed, 31 Jul 1996, Perry E. Metzger wrote:
>
> >
> > Michael Dillon writes:
> > > And the fact of the matter is that we have NO protocols and NO running
> > > code to handle shared registries today.
> >
> > True enough, but neither is a serious challenge. Transaction systems
> > are bothersome to write but are very well understood.
>
> Agreed. It is more a matter of getting the requirements specified, and
> getting the details agreed upon.
>
> > > So if anyone here *SERIOUSLY* wants to see shared TLD's then the
> > > first thing to do is to write a charter for a WG to design those
> > > protocols and get it accepted by the IETF.
> >
> > I believe that this is what we are doing here.
>
> So far I haven't seen a whole bunch of discussion about the text of a
> charter or the timeline. You interested in doing that?
Here's my thoughts on the matter of the charter:
- -------------------------------------------------------------------
DRAFT
Shared Top Level Domains Working Group Charter
The STLDWG will do the following:
1) Define what is meant by "Shared Top Level Domains".
[The brief discussions we have had so far lead me to
believe that there are possibly several different
conceptions of what "Shared Top Level Domains" means.]
2) Develop a set of performance requirements that a STLD must meet
to be considered as a replacement for a non-shared TLD.
3) Examine the technical and administrative issues involved in running
*and* deploying a STLD paradigm.
4) Develop a set of proposed administrative procedures and possibly
technical protocols (at a general level) for running a
STLD. [Since the cohort registries for a STLD will ideally
be competitors, it is especially important that there be
mechanisms in place to prevent cheating, pre-claiming
desirable names, and so on.]
5) Produce an IETF draft that describes the results.
Timeline and milestones:
1) Definition and reqirements document (1 & 2, above) -- Sep 1, 1996
2) Discussion of issues -- arbitrarily marked as complete Oct 1, 1996
3) Development of procedures and protocols -- complete by Jan 1, 1997
4) IETF draft complete -- Mar 1, 1997
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 1 Aug 1996 07:49:04 -0700
From: "Richard J. Sexton"
Subject: Re: Charter
> DRAFT
>
> Shared Top Level Domains Working Group Charter
>
> The STLDWG will do the following:
>
> 1) Define what is meant by "Shared Top Level Domains".
> [The brief discussions we have had so far lead me to
> believe that there are possibly several different
> conceptions of what "Shared Top Level Domains" means.]
Entities that can register a domain independant of the NIC, and each onther
into a common database used by the global internet at large.
>
> 2) Develop a set of performance requirements that a STLD must meet
> to be considered as a replacement for a non-shared TLD.
performance in what area?
>
> 3) Examine the technical and administrative issues involved in running
> *and* deploying a STLD paradigm.
a dtaflow diagram
>
> 4) Develop a set of proposed administrative procedures and possibly
> technical protocols (at a general level) for running a
> STLD. [Since the cohort registries for a STLD will ideally
> be competitors, it is especially important that there be
> mechanisms in place to prevent cheating, pre-claiming
> desirable names, and so on.]
>
> 5) Produce an IETF draft that describes the results.
>
> Timeline and milestones:
>
> 1) Definition and reqirements document (1 & 2, above) -- Sep 1, 1996
>
> 2) Discussion of issues -- arbitrarily marked as complete Oct 1, 1996
>
> 3) Development of procedures and protocols -- complete by Jan 1, 1997
>
> 4) IETF draft complete -- Mar 1, 1997
>
> --
> Kent Crispin "No reason to get excited",
> kent@songbird.com the thief he kindly spoke...
>
the rest looks fine
----------------------------------------------------------------------
Date: 1 Aug 1996 11:50:40 -0700
From: Kent Crispin
Subject: Re: .com
Michael Dillon
[snip]
>
> > > Consensus is irrelevant. The NSF and NSI own .com. Period.
> >
> > I don't believe thats true. Is this your opinion or
> > is this a verifiable fact ?
>
> There is an RFC which talks a bit about this, but documents from NSI, NSF
> and FNC all indicate that they believe this to be the case and I don't
> think it will be easy to change their minds. In particular, check the FNC
> www pages at www.fnc.gov where you can read the minutes of the FNCAC
> meetings at which they decided to let NSI cahrge $50 fees.
I checked this out. Here it is the discussion (at
http://www.fnc.gov/FNCAC_10_95_minutes.html):
George Strawn also described NSF's September 1995 actions in
enacting a new policy for charging for Domain Names, and NSF's
plan for developing a long-term solution. In 1993, NSF awarded a
cooperative agreement to Network Solutions, Inc. (NSI) to
administer the InterNIC, including domain name registration
services. Exponential growth in the Internet, however, has driven
the cost of these services from $1 million per year (original
estimate) to upwards $1 million per month, prompting the interim,
fee-oriented policy change by NSF.
This interim solution includes: an annual fee for DNS names (no
fee for numbers; a $100 initial fee for a two-year period, with a
$50 annual renewal fee thereafter) and requirements for NSI to
place 30% of collected fees into an "intellectual infrastructure"
pool with an NSF-sponsored oversight committee. The policy covers
those domain names which are administered by NSI, including:
".COM", ".NET", ".ORG", ".EDU", and ".GOV". The fees for ".EDU"
will continue to be paid by NSF as a service to the R&E community.
Payments for ".GOV" will temporarily be covered by the NSF. This
policy does not affect ".US" or ".MIL" domain names.
NSI's cooperative agreement ends in 1998. In advance of that
date, NSF will work directly with the Internet community (through
a series of workshops and other means) to construct a long-term
solution. The first of these workshops will be held at Harvard on
November 20th.
Does anyone know more about the Harvard meeting, just out of
curiosity?
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 1 Aug 1996 12:54:27 -0700
From: Michael Dillon
Subject: Re: .com
On Thu, 1 Aug 1996, Kent Crispin wrote:
> Does anyone know more about the Harvard meeting, just out of
> curiosity?
Check http://www.memra.com/ndbg.html for links to stuff like the harvard
meetings.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 1 Aug 1996 13:21:02 -0700
From: Kent Crispin
Subject: Re: .com
Michael Dillon allegedly said:
[snip]
>
> In any single message to this list all of us must focus on simple
> abtractions that we hope accurately describe a portion of the problem in a
> way that leads to better understanding and to a better design for our
> policies. But it is as much a mistake to assume any one person has *THE*
> solution to the entire problem as it is to assume that any one person is
> totally clueless and has nothing to contribute. We are all mere mortals
> here.
I resent that! Who are you saying is not clueless!
(:-))
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 1 Aug 1996 17:06:52 -0700
From: Kent Crispin
Subject: Re: Charter
Richard J. Sexton allegedly said:
>
> > DRAFT
> >
> > Shared Top Level Domains Working Group Charter
> >
> > The STLDWG will do the following:
> >
> > 1) Define what is meant by "Shared Top Level Domains".
> > [The brief discussions we have had so far lead me to
> > believe that there are possibly several different
> > conceptions of what "Shared Top Level Domains" means.]
>
> Entities that can register a domain independant of the NIC, and each onther
> into a common database used by the global internet at large.
Perhaps I should have used the term "Describe" instead of
"Define"...I think we should fill in some detail.
What you have written is perhaps too concise -- I'm not precisely sure
what you mean by "Entities". (It couldn't be "Shared Top Level
Domainss" because then the sentence doesn't make sense -- Domains
don't register themselves). Perhaps something like this:
"A STLD is a TLD for which policies, procedures, protocols, and
algorithms are in place that allow multiple competing registries to
register a subdomain into a common global database used by the
internet at large, independent of the NIC and of each other."
If that is indeed what you mean (presuming my clumsy rewording is
decipherable), then I have a concern: this definition
leaves some lower level terms and phrases that should probably be
defined. For example, what is meant by the term "to register"?
[In an earlier posting I tried to define a registry as something that
maintains an association between a real world entity like a
corporation or an individual, and a domain name. A "nameserver"
maintains the association between domain names and IP addresses. The
current common definition of "registry" actually seems to maintain a
triple: (entity, domain, IPaddr).]
Another thing that is obscure is what is meant by "used by the
internet at large". Is the global shared database just the zone
files for the STLD, which is supplied to root nameservers wherever
they may be?
>
> >
> > 2) Develop a set of performance requirements that a STLD must meet
> > to be considered as a replacement for a non-shared TLD.
>
> performance in what area?
Suppose we have a STLD with 200 cohort registries in Africa, Europe,
Australia, and North America. Here's a sample requirement: It should
be the case that say 98% of the time a database update should
propagate to everyone of them within 15 minutes.
While it may seem obvious, a requirement like this simply cannot be
met (IMHO) if there is a human in the processing loop at each
registry.
But maybe this isn't a good charter item.
> >
> > 3) Examine the technical and administrative issues involved in running
> > *and* deploying a STLD paradigm.
>
> a dtaflow diagram
Do you mean we should have a dataflow diagram as one of the charter
items?
> >
> > 4) Develop a set of proposed administrative procedures and possibly
> > technical protocols (at a general level) for running a
> > STLD. [Since the cohort registries for a STLD will ideally
> > be competitors, it is especially important that there be
> > mechanisms in place to prevent cheating, pre-claiming
> > desirable names, and so on.]
> >
> > 5) Produce an IETF draft that describes the results.
> >
> > Timeline and milestones:
> >
> > 1) Definition and reqirements document (1 & 2, above) -- Sep 1, 1996
> >
> > 2) Discussion of issues -- arbitrarily marked as complete Oct 1, 1996
> >
> > 3) Development of procedures and protocols -- complete by Jan 1, 1997
> >
> > 4) IETF draft complete -- Mar 1, 1997
> >
- --
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
----------------------------------------------------------------------
Date: 1 Aug 1996 22:04:33 -0700
From: johnl@iecc.com (John R Levine)
Subject: Lightweight vs. heavyweight registries
I've been pondering the ways that shared TLDs might work, and I see two
somewhat different ways that the responsibility might be parcelled out:
The heavyweight registry model:
There are a bunch of registries each of which holds a subset of the total
contents of the TLD. Via the magic of a distributed data base, these are
merged on the fly and loaded into the domain servers now and then. Each
registry is presumably a privately owned business. Unless there's been a
lot of progress in distributed databases that I haven't seen, this sounds
awfully tough to make work reliably.
The lightweight registry model:
There's one registry for the TLD, but it's a small and perhaps cooperatively
owned outfit, analogous to DSMI, the telco-owned registry that manages 800
and 888 numbers. The registry has a moderate number of customers, each of
which can register domains for itself or third parties. Customers
communicate using a yet to be defined protocol (which need have nothing to do
with DNS protocols) to send updates to the registry's database, and have a
billing arrangement with the registry. The registry has all the info needed
to update the domain servers for the TLD. The customer-registry interactions
are quite formalized, with the idea that the customers are reasonably clueful
and can be expected to send in well-formed requests.
Following the 800 model, third parties can switch from one customer to
another and take their domains with them. The financial arrangements are
between the third parties and the customers; all the registry does is to
accept a request from a new customer to take over an existing domain entry.
Customers would typically be ISPs and various sorts of Net presence providers
who could offer domain registration by itself or more typically as part of
the package of services they provide. A single ISP or presence provider
would probably sign up as a customer of all of the shared TLDs so it could
provide one-stop service to its users.
It seems to me that the existence of a lightweight registry solves all sorts
of data management problems, since it's a neutral party that can manage the
common database. There's still plenty of opportunity to make money here,
but it's moved one level out from the registry to the first level customers.
One fairly critical assumption here is that anyone is allowed to grab any
available name, so the registry need only make a mechanical check for
duplication. This doesn't work so well for TLDs with some sort of
qualification (e.g., domains open only to registered trademark holders, for
people who believe in that) since it's not clear to me who the gatekeeper
would be. But I expect that in fact most domains will be open to anyone, so
this should work.
- --
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
