Proposal Two: Sample Meta Registrar

[Aveek Datta <MoNoLiTH+@CMU.EDU>]

 [ This proposal was sent to iahc-submit and is on the website ]

[ draft-iahc-datta-meta-registrar.txt ] 
[ Author: Aveek Datta, adatta@ml.org  ]
[ Expires: March 1, 1997              ]

     Sample Meta Registrar

Status

   This proposal has NO official status.

History

   BETA    November 21, 1996     Initial Document Written
   1.0     January 16, 1997      Rewritten and submitted


Abstract

   This document is intended to show AN implementation of a shared registry. 
It was not written to be _the_ system used by CORE as many improvements can
be made. It is here for comparison and discussion purposes. 

Assumptions

   The meta-registrar described here is minimalistic and is intended to be the 
simplest way for both individual registrars and meta-registrar operation.

Meta-Registrar Database

   The meta registrar main database consists of three parts, domain
information, registrar ID, and administrator ID.

Domain Information

   As a top level meta-registrar, a meta-registrar will only be serving
subdomains. Hence in some format, the following data is stored as
Domain Information:

     Full Second Level Domain Name  (aka ml.org)
     Domain Name Servers (unlimited amount)
     For each server: (fully qualified domain name, glue record)
      glue record field ignored if nameserver is not under given SLD

   Unlike the Internic there will be no HOST database, simply because
a given nameserver can have many names.

Registrar ID

   This is a unique ID given to registrars using this meta-registrar.
There will be a separate Registry Database that can contain more
administrative info for lookup purposes. This database can be modeled
after the contact databases used by the Internic.

Administrator ID

   This is the actual administrator of the ID. Only one ID is stored --
this person is equivalent to the Administrative Contact in the current
Internic System. The Technical Contact is considered to be the registrar
itself; it should maintain its own more complete databases. The
administrator ID refers to another database, similar to the registrar
database. 

Technical Implementation

    For generality of use, I suggest using a socket based protocol.
Assuming that, several options arise:

  1) Using Email: It is a reasonable assumption that any registrar
      can easily setup email.
  2) Using Web: In these days it is also possible to use the current
      web based interfaces (see my site).
  3) Using Another Service: FTP or some of the RPC functions are a
      possibility.
  4) Using a specific client/server program.
  5) Using a combination of the above. This is preferred. The meta
      registrar will have "pre-parsers" which will convert sent
      data over any service into data which the final parser can
      use.

    These pre-parsers have to worry about security -- authentication
and encryption of requests made by registries is a high priority.
However, this problem has been dealt with separately in many fashions
and one of those can be adapted for use here. (I know very little
about Computer Security and hence I will not go into that here).

Parsed Data

   A format like the Simple Registrar Protocol proposed by K. Crispin
November 1996 can be used. In any case, this is more an administrative
detail; the form should only ask for the data required for the meta
registrar, no more, no less.

Data Upload

   The simplest way to implement this is have one central server which
recieves requests, timestamps them, and services them in order. Each
request is authenticated, verified, and then dealt with appropiately.
However, with any large system the load on such a central server would
be tremendous. In addition, far away registries (on the Internet) will
have a disadvantage in data travel time to the central server.

   To help resolve this problem, in addition to the central server there
could be several well placed secondary servers. Registrars should
send data to their nearest secondary server. The secondary server
could then do some pre-pre-parsing, if necessary, and then create a 
"packet" of requests every X minutes, hours, etc. All secondary servers
could more or less synchronize their clock and send this packet every
X minutes, hours, etc.

   All secondaries would send their data to the central server, at
about the same time, who would process packets one time period after they
were sent, in order to give time for all secondaries to send data. After
recieving the packets, it would merge them into one large packet, using
random algorithms to settle "ties" on timestamps up to any given
resolution (one minute, etc). After this merged packet is created, the
server would simply linearly serve each packet. 

   For optimization and security purposes, it might make sense to have
two central servers -- one which recieves data but ONLY from the
secondary servers, and then collates/merges this data. Then it sends
the merged packet to a heavily protected central database server which 
processes them. The central database server when done sends another
packet to the central communication server, who then proceeds to
resend out the results of the processing either to secondary servers
or directly to the registries.

   While having secondary servers helps solve some problems, it creates
others -- the security on several secondary servers around the world
is a hard problem to deal with. However that is partly an administrative
issue and partly a programming issue of audits and logs. These issues
can be dealt with.

Data Update

   Registrars are allowed to send in update requests for any domain
that is associated with their ID. The meta-registrar wants to only
receive updates from registries, who it hopes it will operate in a
simple, efficient, and ethical manner. By limiting updates to
registries only, the meta-registrar has only to provide some limited
tech support to the registrars.

   However there are situations when a registrar abuses the system.
For this, creation of an oversight committee which will take and
investigate requests directly from the user. This is only as a last
resort and multiple complaints against any given registrar should
be grounds to removal of registrar privileges.

   In any case a user may petition the committee to 
   a) change the hostname administrator ID
   b) change the hostname registrar ID
in cases where a registrar either 'illegally' removes a user from the
administrator slot, or where a registrar refuses to relinquish rights
to another registrar. 

Estimated Costs

These are nothing more than my guesses.

   Hardware (Central Server(s))       $10,000
   Connectivity       (hopefully located with some major ISP,
                       so minimal setup charge)
   Software Creation                  $30,000
    Proposed: Two month creation period where one administrator/programmer
      and three programmers are hired to work full time to implement
      this software. 
   Software Beta-Testing              $10,000-$20,000
    Proposed: Two-three month period where the above staff works part-time
      outside of the administrator to resolve bugs.
   Annual Personnel Charge            $50,000
    Proposed: All that is needed is one full time administrator,
      preferably the original one.
   Annual Connectivity and Plant Charge $10,000
   Administrative Oversight Committee (per year)  $40,000
    Proposed: Open Internet process overseen part time by compensated
      Internet 'engineers'.
   Secondary Server Cost              see below
   Etc                  $??,???

   The organization should be a non-profit. Fees should be paid to
cover the above costs. Registrars should be encouraged (by credit
towards the fee) for providing secondary servers, both DNS and
possibly the type outlined above.

Legal Issues

I am not a lawyer or even very knowledgeable about the law.

   The meta-registrar should just be considered a repository for data
that is maintained by the registrar listed and owned by the ID listed.
As such, a contract should be signed that the meta registrar only
serves these names and assures that there are no conflicts. Outside
of that, all policy is set by the registrats themselves and hence
they should be held accountable for the data.

Conclusion

   The meta-registrar modeled here is not applicable directly for
what the IAHC needs. However I hope it stimulates some thought and
provides some insight into how this *could* work. Comments and questions
are welcome. Email is preferred.

Contact Information

This text written and copyright 1997 by

   Aveek Datta                        adatta@ml.org
   c/o Monolith Coalition             http://datta.ml.org
   Box 8159                           Phone 412-862-2661
   Pittsburgh PA 15217                Pager 412-686-9742

   Network Administrator Monolith Coalition Free Internet Services,
    including world's largest free 3rd level registry, http://www.ml.org

Permission to copy this document as long as credit is given.
Permission to place on IAHC website is given.

 Aveek Datta           _ _ _   _                Email: aveek@andrew.cmu.edu
    _ __  ___ _ _  ___| (_) |_| |_     |W|   HomePage:         datta.ml.org
  _| '  \/ _ \ ' \/ _ \ | |  _| ' \ _  |E|    FreeDNS:           www.ml.org
 (_)_|_|_\___/_||_\___/_|_|\__|_||_(_) |B|       Work:      www.itc.cmu.edu
   Please do not CC: mailing list messages/responses to me through email.