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@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@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 * -------------------------------------------------------------------------- *