Re: what should be COREdb contain (was: Re: Anti Capitalism?)

[davidk@ISI.EDU]

Rick,

> Rick H. Wesson writes :
> 
> On Jan 3,  4:46pm, davidk@ISI.EDU wrote:
> > > Rick H. Wesson writes :
> > >
> > > The info for the Name Servers has to stay in the back end regestrie.
> >
> > Either I was unclear or you misunderstood me:
> >
> > I agree with this (as stated in my previous mail):
> >
> > > On Jan 3,  3:45pm, davidk@ISI.EDU wrote:
> > > > The repository should be as lightweight as possible, that is:
> > > > ...
> > > > - DNS configuration data (nameservers)
> > > > ...
> >
> > > If I want to regestter a domain and list a set of name servers, the contact
> > > of each one of those name servers must be sent an ack/nak request. I would
> 
> I was speaking as a front end regestrie. Contacts may move between Front
> End Regestries (FER) Contacts don't have to regester with each regestry.
> If the contact data resides in the Back End Regestrie (BER) it won't be
> duplicated.

True. But you will see that the data gets duplicated anyway. I don't see
any registrar using the repository database as the database for their
internal data. They will always have a local copy for at least the
administrative contacts ...

Registrars will have to have their own policies for whom to trust. It
doesn't help to do this centrally. It only puts more strain on the
central authority since it will be in between when there are conflicts.
And who is going to clean up the stale data in the repository ? (note: I
am speaking from my own experience now, I once was the man behind a 
central repository :-(). I strongly argue for keeping all the dirt out of
the central repository and use it where it is designed for sharing a TLD
and configure the root name servers.

The key to this problem is the end-user. The end-user will only use
contacts that they trust (that implies that they trust the registrar
where the contact information is stored) or they don't trust them and
register their own data with the registrar. 

There is no difference with the centralized approach. The only difference
is that the data is stored at another place. There is no guarantee
whatsoever that the registrar stores the right information in the
repository. The end-user still needs to trust the other registrar since
the other registrar can still decide to get rid of the contact
information in the central database since it is authoritive about it.
Schemes that give authority in an AND kind fashion (that is, all
registrars need to approve a change) don't work in practice since
everybody will end up waiting for each other and the data will get
hopelessly out of date. And guess what ? People solve this by creating
duplicate objects... I found from my experience at RIPE that the key to data integrity turned
out to be ease of use. People will just not bother to update info if it
is too complicated.

Note that technical contacts are not of vital importance to the whole
process although we of course like to have them right. There will always
be a problem with the consistency of technical contact data when storing
the data outside the end-users own server. Unfortunately, the solution
for storing the contact information at the end-users site that is
available today (DNS) might not work when we have a DNS failure ... Other
approaches as we want to do with RIDE are certainly not ready. I am
afraid that you just identified the problem that is most difficult for
any registry database.

> IMHO the Front End Regestries have no reason to allow another Front
> End Regestrie (FER) to access its data. All the Front End Regestries
> are in competition and can't be trusted. Thats why you need to logicly
> seporate ownership of objects in the Bak End Regestrie (BER.)

They have a reason to share their contact information:

- it hurts themselves, the other registars will make life
  difficult for the bad guy
  
- the IAHC can require that registars need to publish their data

- technical contact information is not the most vital part (to keep
  secret) for the registrars business
  
- the end-user will request cooperation
  (how come that the Internet works with thousands of ISPs in cut-throat
   competition)
  
I know it's not perfect, but not all problems have perfect solutions
since we are dealing with humans ;-(,

David K.
---