From engin@ripe.net Thu Dec 5 13:25:05 2002

Dear Engin,

...

I have one question though: who will be the maintainer of the new "ugly" object created? I have the feeling it could/should be the maintainer of the object that will reference it.

That would make sense, when creating person objects, I think. However, thinking about role objects that will be created: If we put the once-inconsistent object's maintainer on it, the users that happen to have the referenced name but have no relation to the inconsistent object will not be able to delete their NIC handle from the newly created role object. They will need to contact the owners of once-inconsistent object, however chances are that they will be irresponsive (otherwise they would have updated their inconsistent objects long ago, wouldn't they ;)

So I'd propose putting mntners of relevant inconsistent object in the new person object, but leaving the new role objects unmaintained. What do you think?

Yes, this makes much more sense, indeed. I have a new question, though (I quote from the original proposal):

From db-wg-admin@ripe.net Thu Dec 5 10:43:33 2002 From: Engin Gunduz <engin@ripe.net>

1. Objects that refer to a person or role object by name. a. There is only one object with this name. Solution: Update the inconsistent object so that it will contain the NIC handle instead of the name. Add appropriate remarks and changed attributes to the object to explain the reason for update.

In case the referring object is maintained (by a probably unresponsive maintainer, as you well suggested above) and the referred person happens not to be related to the referring object (i.e. the program inferred incorrectly the relationship), then the owner/maintainer of the object will not be able to delete the person object once it becomes unused. Would it not be advisable then to act as in case 1.c. (with a single person/role object being referenced by the newly created role object)? In other words, it may be advisable to refine 1.a. by the following: 1.a.1. If the referring object is maintained, and the maintainer is different from the maintainer of the object with the referred name, then proceed as in 1.c. (If the latter object is not maintained, then the maintainers are by definition different.) 1.a.2. If the referring object is unmaintained or both objects are maintained by the same maintainer, then proceed as previously described. This procedure may create superfluous role objects, but I would think the chances are low for this to happen and it is a price worth paying. What do you think? Best regards, Janos