Re: CORE Implementations

[davidk@ISI.EDU]

Rick,

> Rick H. Wesson writes :
> 
> Yesterday David Kessins proposed a light weight backend database
> archature. At first I didn't like his idea. So I wrote an implementation
> where only the name server and domain name are managed, and the rest of the
> contact data is distributed.
> 
> Below are my findings.
> 
> Distributed Contact Data
>     o Easyer to manage.
>     o Smaller database
>     o Faster (20 Allocations a second )
>     o One person could manage the system.
>     o No refrencial integraty
>     o Better case for a dedicated regestry business
> 
> Centralized Contact Data.
>     o Larger API
>     o More strict checking
>     o Strict refrencial integraty
>     o Regestry business will be a Value Add by ISPs
>     o Costs more to manage.
> 
> Conclusion
> While both are viable archatures, in the case of
> distributed contact data, there is virtually no refrencial integraty for the
> system. The CORE DB trusts that front end regestries to enter valid
> contact data and there is no way to ensure that the contact data is
> valid. Otherwize the Centralized method should be easyer to manage
> and pay for.
> 
> If anyone would like to see my implementation where contact data
> is distributed drop me a note and I'll e-mail it to you.
> 
> What it comes down to is basic database design, under the distributed
> system there is no refrencial integraty to the system but it costs
> less to run. In laymans terms the centralized regestry could not have
> handles that point to objects that don't exist.

I think that you made a good summary of the two different proposals.
I have two notes though:

- There are some possibilities in between. One can do the distribution
  even more aggressively then I proposed or choose something in between
  the current proposals. 

- The integrity of the referencial data is less of a problem then it
  looks at first sight:
  
  - one can safely assume that the registrar *always* knows the
    administrative and/or billing contact of the domain (and could be
    required to publish it whether it is by (r)whois(++)/DNS/anything
    else). This should satisfy the lawyers ;-). I don't think that any
    registrar will accept storing such vital data in another database,
    whether it is another registrar or the central repository. And if the
    registrar goes out of business:
    
  - contact data could (additionnally) be stored local to the end-users
    site. There are very simple ways to do this: define a standard port
    and let inetd call 'cat /etc/contact.info', 'whois -h my-registrar
    my-handle' or use DNS TXT records. We can even let the end-user
    (electronically) sign an agreement that the central repository can
    remove domains if one doesn't seem to have useful data available and
    somebody tried to contact the domain holder for legal reasons (IAHC
    needs to define what 'trying to contact' means). I even see a much
    broader application for this idea since there are other problems one
    can have then DNS alone ... Note, that data tends to be more up to
    date when it is actually used, that is, we should encourage the reuse
    of the contact information for other related activities.

  - data tends to be maintained much better if it is easy to update and
    often used. Security mechanisms or very centrally organized systems
    can defeat their own purpose. This means that it is easy to get bad
    information even if you have all the right relations in your central
    DB. Remember that end-users are (still :-() smarter then machines,
    it's easy to submit incorrect information or not updating it at all. 
    This is even more true in an international context where addresses
    don't look everywhere the same. It is for example nearly impossible
    if a certain address really exists in another country. Systems more
    local to the user tend to be easier to keep up to date.

And yes, I am not going to tell again what I think about the lottery and
the 60 day wait period, just read the archives ;-),

David K.
---