Adding nic handles to contact objects without one
Dear all, during the last RIPE meeting, in Amsterdam, the database working group discussed a proposal to automatically add NIC Handles to all person and role objects in the RIPE Database that don't yet have one (new objects can't be created without nic handles anymore). This proposal was supported by the working group and it was agreed that it should be circulated to the mailing lists to give people not attending a chance to provide input. This does not affect how other objects reference these person or role objects. This is only intended to bring old objects into conformance with the current object definitions and does not mean that data provided by the user will be modified. Only the nic handle attribute will be given a value when the object lacks one. No other attributes will be touched. Objects which already have nic handles will not be touched. The nic handle is a tag conveying no information about the user or role described in the object. It is an identifier for the object. This addition would make data more uniform and could be a benefit for everyone. For more information on nic handles, please read RIPE 157 and RIPE 189 available at http://www.ripe.net/docs Best regards, Joao Damas Database Group RIPE NCC
Hi Joao, I'd like to know what exactly are the advantages (and to whom) to adding a nic-hdl to person objects which don't already have one ? In some cases a person (without a nic-hdl) has their name referenced in other Db objects. This was before nic-hdls were mandatory. So if you add a nic-hdl to such a person's person object what can be done to those objects which reference his/her name ? There is no way of distinguishing the names referenced in the contact attributes of these objects since a similar name can refer to different people. Then you have the problem where these people created a new person object for themselves when nic-hdls became mandatory and left their old person object for dead. How will you overcome these old person objects ? Lots of questions which were not discussed at RIPE32. Regards, Eamonn McGuinness RIPE NCC Hostmaster In message <199902251709.SAA00968@x41.ripe.net>you write:
Dear all, during the last RIPE meeting, in Amsterdam, the database working group discussed a proposal to automatically add NIC Handles to all person and role objects in the RIPE Database that don't yet have one (new objects can't be created without nic handles anymore). This proposal was supported by the working group and it was agreed that it should be circulated to the mailing lists to give people not attending a chance to provide input.
This does not affect how other objects reference these person or role objects. This is only intended to bring old objects into conformance with the current object definitions and does not mean that data provided by the user will be modified. Only the nic handle attribute will be given a value when the object lacks one. No other attributes will be touched. Objects which already have nic handles will not be touched. The nic handle is a tag conveying no information about the user or role described in the object. It is an identifier for the object.
This addition would make data more uniform and could be a benefit for everyone .
For more information on nic handles, please read RIPE 157 and RIPE 189 available at http://www.ripe.net/docs
Best regards, Joao Damas Database Group RIPE NCC
Hello, "Eamonn" <Eamonn@ripe.net> writes: * * Hi Joao, * * I'd like to know what exactly are the advantages (and to whom) to * adding a nic-hdl to person objects which don't already have one ? * I think there are benefits for everyone. The database becomes more coherent, ambiguity between different people with the same name disappears (especially if as you say below, references by name are then substituted by references to NIC Handles). * In some cases a person (without a nic-hdl) has their name referenced * in other Db objects. This was before nic-hdls were mandatory. So if * you add a nic-hdl to such a person's person object what can be done to * those objects which reference his/her name ? That, I think, is a discussion for these lists. Either the user does it or the RIPE NCC can do it if users wish to. Of course this can only be done for references by name corresponding to names that are unique in the database, otherwise we wouldn't know who to assign the object to and we shouldn't. * * There is no way of distinguishing the names referenced in the contact * attributes of these objects since a similar name can refer to * different people. * Indeed. * Then you have the problem where these people created a new person * object for themselves when nic-hdls became mandatory and left their * old person object for dead. How will you overcome these old person * objects ? * Yes, that happened in the past. The software can cope with that now so we shouldn't see cases like those any more. The cleanup I think is best done within the consistency project which is right now regaining speed (more on that soon...) Regards, Joao Damas RIPE NCC
Hello, Joao Luis Silva Damas <joao@ripe.net> writes:
"Eamonn" <Eamonn@ripe.net> writes: * * Hi Joao, * * I'd like to know what exactly are the advantages (and to whom) to * adding a nic-hdl to person objects which don't already have one ? *
I think there are benefits for everyone. The database becomes more coherent, ambiguity between different people with the same name disappears (especially if as you say below, references by name are then substituted by references to NIC Handles).
* In some cases a person (without a nic-hdl) has their name referenced * in other Db objects. This was before nic-hdls were mandatory. So if * you add a nic-hdl to such a person's person object what can be done to * those objects which reference his/her name ?
That, I think, is a discussion for these lists. Either the user does it or the RIPE NCC can do it if users wish to. Of course this can only be done for references by name corresponding to names that are unique in the database, otherwise we wouldn't know who to assign the object to and we shouldn't.
It would be a great pleasure for us, if the RIPE NCC could do this task. We have some very old assigments which lack the nic-hdls. So if we only had to sort out the ambigious person objects it would be very helpful. But...
* * There is no way of distinguishing the names referenced in the contact * attributes of these objects since a similar name can refer to * different people. *
Indeed.
it should be remarked that the person object has been assigned a nic-handle by the RIPE-NCC so that a human can easier recognize the old object and can update the referenced objects. For example: remarks: nic-handle added by the RIPE-NCC consistency project (19990301)
* Then you have the problem where these people created a new person * object for themselves when nic-hdls became mandatory and left their * old person object for dead. How will you overcome these old person * objects ? *
Yes, that happened in the past. The software can cope with that now so we shouldn't see cases like those any more. The cleanup I think is best done within the consistency project which is right now regaining speed (more on that soon...)
Regards, Andreas Wittkemper NIC & DNS Team UUNET Deutschland GmbH Tel. +49 231 972 00 Emil-Figge-Stra_e 80 Fax. +49 231 972 1177 44227 Dortmund, Germany Andreas.Wittkemper@de.uu.net URL: http://www.uunet.de
Folks,
"Eamonn" <Eamonn@ripe.net> writes: * I'd like to know what exactly are the advantages (and to whom) to * adding a nic-hdl to person objects which don't already have one ? I think there are benefits for everyone. The database becomes more coherent, ambiguity between different people with the same name disappears (especially if as you say below, references by name are then substituted by references to NIC Handles).
This is a non-advantage because
RIPE NCC can do it if users wish to. Of course this can only be done for references by name corresponding to names that are unique in the database, otherwise we wouldn't know who to assign the object to and we shouldn't.
the existing ambiguity will *not* disappear.
* Then you have the problem where these people created a new person * object for themselves when nic-hdls became mandatory and left their * old person object for dead. How will you overcome these old person * objects ?
Let me also point out that there appear to exist (inetnum) objects that reference non-existing person objects. If a new person object is created such that the name happens to match, that person will then inherit the reference. This may or may not be intentional (e.g. replacing a person object with a role object where the new role object has the same handle as the old person object :-) On the other hand, just because someone who used to have something to do with an inetnum in (say) Norway and another Person with the same name but from (say) Switzerland appears in the database, if the .no guy's person record got deleted, then the .ch guy has nothing to do with the .no inetnums. Even as of now, I cannot delete old person objects in cases where names are referenced and objects with the same name are still in the database :-( What I am getting at is that if you add handles to all person objects and then update the references from person names to handles, the effect is not necessarily correct. You cannot make a non-consistent database consistent by automatic measures. Just my ECU 0.02 Greetings Bernard
Hello, "Bernard Steiner" <bs@eunet.ch> writes: * * This is a non-advantage because * Actually it is from a database point of view because you increase coherency between the objects and their definition. It also facilitates further work on the DB to eliminate ambiguity. * > RIPE NCC can do it if users wish to. Of course this can only be done for * > references by name corresponding to names that are unique in the database, * * > otherwise we wouldn't know who to assign the object to and we shouldn't. * * the existing ambiguity will *not* disappear. * Yes. That's what I said in my previous mail. Ambiguity will not disappear just by doing this. The users with that kind of objects would have to fix them. The RIPE NCC will aid the users through the database consistency project. This is a first step that doesn't solve all the problems but makes it easier for the future and adds a bit more coherency to the Database. So, I think we agree and I hope you can support the addition of the NIC handles to the objects that don't have one yet. * > * Then you have the problem where these people created a new person * > * object for themselves when nic-hdls became mandatory and left their * > * old person object for dead. How will you overcome these old person * > * objects ? * * Let me also point out that there appear to exist (inetnum) objects that * reference non-existing person objects. If a new person object is created * such that the name happens to match, that person will then inherit the * reference. This can't happen anymore. Now the DB code will not allow a deletion of a person/role object that is still being referenced by other objects. The ones that are already there will have to be fixed, again by the user with our help if it is requested. The consistency project will soon start publishing reports on the occurrence of various types of inconsistencies in the database together with instructions on how to fix them. * This may or may not be intentional (e.g. replacing a person objec * t * with a role object where the new role object has the same handle as the old * person object :-) * On the other hand, just because someone who used to have something to do * with an inetnum in (say) Norway and another Person with the same name but * from (say) Switzerland appears in the database, if the .no guy's person reco * rd * got deleted, then the .ch guy has nothing to do with the .no inetnums. * Even as of now, I cannot delete old person objects in cases where names are * referenced and objects with the same name are still in the database :-( * * What I am getting at is that if you add handles to all person objects and * then update the references from person names to handles, the effect is not * necessarily correct. You cannot make a non-consistent database consistent by * automatic measures. * Again I agree. That's what I stated in the previous mail. No amount of code can subsitute a reasonable person so the real cleanup will need some user intervention. * Just my ECU 0.02 Most welcome [although the ECU is now gone :-) ] Regards, Joao Damas RIPE NCC * Greetings * Bernard
participants (4)
-
Andreas.Wittkemper＠de.uu.net -
Bernard Steiner -
Eamonn -
Joao Luis Silva Damas