Modifying references to contact info in the RIPE DB
Dear all, the Database consistency project has been going forward in its goals since RIPE 33 (eg. addition of nic handles to all objects without one.) Statistics and reports about the "status" of the database can be seen at http://www.ripe.net/db/state/. We will keep adding information to these pages as the project progresses. We are now at the point where we would like to tackle the issue of references by name in the admin-c, tech-c and zone-c. As a next step, we would like to have references by nic handles (which are unique) instead of references by name (which can be non -unique). At this point, we would like to automatically go through all the references by name which can uniquely be assigned to a person or role object and substitute them by references to their nic handles. This will prevent these references from becoming non-unqiue in the future. Later we will go through the process of fixing the non-unique references left in the database. This process requires user intervention since we can't decide who "owns" a particular set of resources. For this later stage, we will be preparing reports that we will send to all maintainers for whom we detect objects with inconsistencies and try to get them fixed. Information about this part will be sent to the lists in a few weeks. We would like to do this after as much as possible has been done by automatic means to correct inconsistencies so that human effort is reduced to a minimum. If there are any concerns regarding this move, please make them known before next Friday (June 25th). Looking forward to your comments, Joao Damas Database Group RIPE NCC
Hi there,
At this point, we would like to automatically go through all the references by name which can uniquely be assigned to a person or role object and substitute them by references to their nic handles.
Later we will go through the process of fixing the non-unique references left in the database. This process requires user intervention since we can't decide who "owns" a particular set of resources. For this later stage, we will be preparing reports that we will send to all maintainers for whom we detect objects with inconsistencies and try to get them fixed. Information about this part will be sent to the lists in a few weeks.
I would suggest to send change suggestions to maintainers, or maintainers of supernets, instead of doing automatic changes. I have the feeling that some person objects may have been deleted and person objects with the same name may have been inserted, and the two people may be different. Automatically attaching objects to the wrong person instead of realizing that the person reference is broken is not really good for database consistency. Just my Rp. 10 (CHF 0.05 being the smallest coin ;-) Bernard
Thanks for the comments on this item. We do realize that there might be a few cases where the possibility raised actually happens: That the original person referenced got deleted some time in the past and a new one with the same name was introduced into the database. However, contacting the holders of all the affected objects is really not feasible and I think also not practical (the order of magnitude is 10^5 objects that would get touched). We could actually send out all these emails and write a mail robot to process the responses. However, with the respondent being a human being, the chances are that a lot of mails would not be be able to be automatically processed. And a lot of people would not even reply. Also, many people not affected by the problem (being the correct reference) would get (unsolicited) emails. I would therefore not be able to extract a valid conclusion from the process. In the meantime, not carrying out the proposed modifications can only make the situation worse (as more person get registered in the database the chances of any two having the same name increase, and old person objects can get deleted). I think at this point there is not a perfect solution for this situation but I would rather deal with the few complaints about an object pointing to someone incorrect (and then act on them) rather than let the situation keep on deteriorating. One of the solutions to catch some of the misassignements (at least for inetnums) is to run a cross check of the database objects against the registry database. 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? Regards, Joao Damas DB Group RIPE NCC
That the original person referenced got deleted some time in the past and a new one with the same name was introduced into the database.
Coming to think about it... How about catching such (obvious) cases where the first changed date of the person is younger or either of the changed dates is not available ? How much human intelligence would that require to sort out ? Bernard
Bernard Steiner <bs@eunet.ch> writes: * * > That the original person referenced got deleted some time in the past and * a new one with the same name was introduced into the database. * * Coming to think about it... * How about catching such (obvious) cases where the first changed date of the * person is younger or either of the changed dates is not available ? * How much human intelligence would that require to sort out ? As a philosopher said some time ago: "I am me and my circumstances". This also applies to the RIPE Database (and in a very big measure). I guess everyone remembers the (in)famous -c changes and how many changed lines (particularly the old ones) disappeared during that period. We can do the check you propose and see how many objects would not get modified. If it happens to be a small number we can look at them individually. If not it is back to square one. Thanks for the suggestion, Joao * * Bernard * *
Talking about the database and consistency of same: The following LIRs all have 100 or more IP numbers in use which are not correctly registered in the RIPE database. Detailed information available at: http://stat.cybercity.dk/ripe Poul-Henning se.swipnet 3842 nl.wapi 2650 uk.global 1477 uk.demon 986 uk.pipex 945 pl.tpsa 857 se.sunet 804 uk.pol 520 fi.kolumbus 507 fr.isdnet 501 it.iunet 459 uk.telinco 363 si.telekom 309 ch.swissonline 282 uk.ntli 272 de.maz 271 dk.teledanmark 269 tr.superonline 259 uk.force9 249 eu.eunet 198 it.flashnet 186 eu.compuserve 180 ch.petrel 169 de.ginko 155 hu.datanet 152 de.rak 147 dk.sektornet 139 dk.proventum 132 fr.cybercable 130 pt.ipglobal 127 de.mediaways 126 se.transpac 123 de.cybernet 107 nl.demon 104 de.roka 103 dk.euroconnect 103 se.umdac 101 -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
Bernard Steiner writes:
That the original person referenced got deleted some time in the past and a new one with the same name was introduced into the database.
Coming to think about it... How about catching such (obvious) cases where the first changed date of the person is younger or either of the changed dates is not available ? How much human intelligence would that require to sort out ?
Probably not too much, but ... there are (quite a considerable number of) LIRs that insist in keeping only the very last changed line. -- Ulf Kieber email: kieber@ga-telecom.net Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-66 internet solutions for business www : www.ga-telecom.net
participants (4)
-
Bernard Steiner -
Joao Luis Silva Damas -
kieber＠ga-telecom.net -
Poul-Henning Kamp