Modifying references to contact info in the RIPE DB

Hi,

throwing some more brain cycles at it...

At least for inetnums, we do have an alternate source of info to check 
against. Our internal registry database. But guess what. On registries that 
have been around for some time, contact info is stored with references by 
name, not nic handle. Those are also the DB objects that have references by 
name. So... one gains nothing from doing this.

What I am trying to do here is minimize the amount of human intervention. On 
all sides.

Let's have an example.

What if I want to contact an admin-c (since they seem to be popular lately) 
for an object.
If the reference is by name then when I query the DB I will get the list of 
persons with that name, right?
Whether the object belongs to the person or not is not going to save this 
person from being contacted. From the point of view of the database and the 
user querying it, the object belongs to that person.

The link is via a name.

Now we substitute the reference by name with a reference by nic handle 
pointing to the same person.
What is the difference?

ALMOST NONE except that:
from that point on if someone else with a name equal to one already in the 
database is entered into the database the reference will not be made ambiguous 
while if we leave it as a reference by name it sure becomes ambiguous.

If I am being pointed at by some object in the DB because the original person 
went away, then it is not going to help me whether the reference is by name or 
nic handle. However, having references by nic handle can stop at least this 
kind of deterioration.

We will still have problems with objects that have references by name when 
there are already several person with the same name. But we are not going to 
chose those in this run. This is aimed at stopping this last set from 
increasing.
We'll tackle the current ambiguities in the (near) future.

Hope this made things a bit more clear,
Joao


 "Wilfried Woeber, UniVie/ACOnet" <woeber at cc.univie.ac.at> writes:
 *   Hi Joao!
 * 
 * >So, in spite of the concerns raised (valid as they are) I would still
 * >vote to go ahead on this one as proposed.
 * >
 * >What do people think?
 * 
 *   Well, some as yet unstructured rants, off the top of my head...
 *   
 *   I'd love to see some sort of test-run being performed, e.g. going 
 *   ahead and putting the result up as the (or an additional) test db?
 *   
 *   One of the key things might be to make sure that we (you :-) can perform
 *   a roll-back, if it turns out that we've messed up things badly...
 *   
 *   Is there any chance to do some sort of dry-run, and put up some sort of
 *   list of cases deserving investigation? Poul's page is a very good thing,
 *   indeed, although tackling a different aspect.
 *   
 *   My reasoning is that whatever can be fixed by humans, in a distributed
 *   project, before the brute-force attack would make life easier.
 *   
 *   Most probably basic rule #1 applies to my comments: 
 *   		use the brain before using the keyboard :-)
 * 	
 *   Wilfried.
 *  --------------------------------------------------------------------------
 *   Wilfried Woeber                :  e-mail: Woeber at CC.UniVie.ac.at
 *   Computer Center - ACOnet       :  Tel: +43 1 4277 - 140 33
 *   Vienna University              :  Fax: +43 1 4277 - 9 140
 *   Universitaetsstrasse 7         :  RIPE-DB (&NIC) Handle: WW144
 *   A-1010 Vienna, Austria, Europe :  PGP public key ID 0xF0ACB369
 *  --------------------------------------------------------------------------
 *