[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IAHC Process
- Date: Sun, 24 Nov 1996 00:26:15 -0800
- From: "Rick H. Wesson" <wessorh@ar.com>
- Subject: Re: IAHC Process
On Nov 23, 9:54pm, Kent Crispin wrote:
> Subject: Re: IAHC Process
> Gordon A. Lew allegedly said:
> >
> > I've been lurking on this group since its inception, sometimes with
> > awe, sometimes with amusement and too often with dismay. The
> > increasing threat of legal action on the part of those who feel they
> > may not get their own way inspires absolute disgust on my part.
> >
> > My feelings are that the IAHC's main task is the establishment of
> > Policy (technical and political), as opposed to determining the
> > mechanics of technical implementation of this policy.
> >
> > Mention has been made of Meta-registries, and the use of shared TLDs
> > vs exclusive TLDs.
> >
> > So what is required of such an animal?
> >
> > 1. 24/7 operation (staffing, power, network, etc.)
> > 2. Capable of high volume real-time inputs/outputs (>500 per second)
> > 3. Massive data base capability
> > 4. Data base look-up, update, search (even on fuzzy inputs)
> > 5. Real-time data base update
> > 6. Ability to guarantee non-duplicate entries
> > 7. 24 hr help desk availability
> > 8. Ability to service large numbers of registry agents (>5000 if
> > required)
> > 9. Ubiquitous network availability (global)
>
> [Comments about SABRE deleted]
>
> Your requirements are based on the idea, I believe, that there is a
> single meta-registry for all TLDs. This is, IMO, both unnecessary and
> undesirable. Each TLD is a separate domain as far as synchronization
> between shared registries is concerned. Furthermore, the only real
> synchronization needed is to be sure that two different registries for
> the TLD don't give out the same Second Level Domain name. In
> principal, different TLDs could use totally different mechanisms -- a
> very low volume TLD with only a few registries could be synchronized
> with email messages between them, for example. Only in the case of
> a very heavily used TLD like .com does the level of performance required
> come even come close to your requirements.
IMHO A well defined protocol should be defined and relied upon insted of
a loosly defined e-mail process. If anythig this 'protocol' would enable
all regestries to viewed by the regestrant through a simular interface.
> Furthermore, there already is a database that comes very close to
> meeting all your requirements -- DNS itself. The Dynamic Update
> extensions, with DNSSEC, have almost all the functionality required
> to support shared TLDs.
DNSSEC extentions do not allow the management of (handles)
contact data. Altough DNSSEC has some feature that my benifit
iTLD regestries they don't provide the access to or management of
meta data that is very important to ommercial regestries as
in billing.
-Rick
--
Rick H. Wesson