IAHC Process

["Gordon A. Lew" <glew@ionet.net>]

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)

Earlier, David Conrad asked how some of the proposed requirements 
stacked up against airline reservation systems.  In many ways, this 
suggestion answers that question and many others.

In looking at this problem, these requirements, and bearing in mind
my knowledge of the capabilities of the SABRE system, I would offer
the following for all to consider:

The SABRE System meets ALL of the requirements listed above.

The additional system software required, while not trivial, lies well 
within the expertise of the programming staff, and could be expected 
to be implemented within a reasonable time.  

If the IAHC were to initiate a contract with SABRE to act as the neutral
meta-registry, the mechanisms to request/assign TLDs AND SLDs would be a
relatively trivial task.  

Registries would attach to a subset of the SABRE system using SABRE
provided terminal(s) -  (yes, there's world-wide connectivity), and
then using a template displayed on the terminal, request the desired
TLD (or SLD - let me use the term xnLD).  The nLD would be checked for
duplication, for meeting policy requirements (which might involve
trade-mark lookup), for completeness, etc., and the nLD would be
assigned in a matter of seconds.

Potential problems due to policy conflicts would be automatically
referred to a terminal/printer at IANA or it's successor (and in 
real-time).  

Since there will be $$ involved somewhere, each registry would be
required to pay, say a monthly charge for the terminal along with a
fixed fee for each registered nLD.  The use of SABRE
terminals/connectivity ensures that only authorized registries would
be involved.  What these guys charged their end users is another
story.

The updated info would then be sent to root servers at regular 
specified intervals (each minute, hour, day, whatever) directly from
SABRE.

This inherently makes all nLDs shared, with the exception of those
programatically reserved, such as .mil, etc.

If this mechanism were thrown into the arena, it could easily 
generate a new thread by itself, leaving the iahc-discuss group
free to get on with policy!

This is a very fast pass at this, and there are many wrinkles
which would pop up, but as a very high-level concept, as a group,
what is your take on it?

Disclaimer:  I am no longer an employee of American Airlines, nor of 
the SABRE Group.  (I retired in 1995)  My mention of Sabre and its
capabilities comes from working with the system and its networks
for over 27 years.  I haven't contacted anyone at SABRE as to the
contents of this message, nor, to the best of my knowledge, are they
even aware of the existence of the IAHC.

----------------
Gordon A. Lew
glew@ionet.net