[Apologies for duplicate messages] Dear Colleagues, On 2002-12-20 11:44:44 +0100, Engin Gunduz wrote:
[Apologies for duplicate messages]
Dear Colleagues,
I'm attaching the updated proposal for automatically cleaning up the references by name in RIPE Whois Database. We have incorporated Janos's suggestions to the proposal.
If no more comments come, we plan to apply the procedure described in the proposal in the first half of January, 2003. The operation should not take more than a day. We will notify the community about the actual date of the operation.
We plan to perform the clean-up - on January 15, Wednesday (tomorrow), afternoon (CET) on TEST database, - on January 16, Thursday, afternoon (CET) on RIPE database. The operation will take several hours, however during the operation the queries and updates will continue as normal. Best regards, Engin Gunduz ____________________________ RIPE NCC Database Group
Regards,
Engin Gunduz ____________________________ RIPE NCC Database Group
-------------- Proposed solution for cleaning up references by name and other invalid references in RIPE Whois Database
Motivation:
References by name and invalid references cause two main problems: 1. One reference by name in a single object locks all person and role objects with that name, that is, they cannot be deleted, because of referential integrity checks. 2. Having anything other than a NIC handle as a reference makes the implementation of whois database software considerably more complex, since the software needs to deal with these exceptions. This increases the coding time, maintenance time and testing time of the software.
Classification of the inconsistencies we need to solve and proposed solutions:
1. Objects that refer to a person or role object by name. a. There is only one object with this name. 1. The referring inconsistent object is not maintained, or the maintainers of referring inconsistent object and the person/role object with this name are the same. Solution: Update the referring 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. 2. The referring object is maintained, and the maintainers are different from the maintainers of the object with the referred name (If the latter object is not maintained, then the maintainers are by definition different.) Solution: Create a role object with this name. It will list the role or person object with this name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. b. There is no person or role object with this name: Solution: Create a person object with this name. Clearly mark this new object putting appropriate remarks attributes so that users will see it is actually a dummy object. Update the inconsistent object to refer to the NIC handle of this new person object. Add appropriate remarks and changed attributes to the object to explain the reason for update. Protect it with the inconsistent object's maintainer(s). c. There are multiple person and role objects with this name. Solution: Create a role object with this name. It will list all the other role and person objects with the same name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. Objects that refer to a non-existent NIC handle. Solution: Create a person object with that NIC handle. Clearly mark this new object so that users will see it is actually a dummy object. Name it "person: Place Holder Object". Protect it with the inconsistent object's maintainer(s). Note that there is no need to update the inconsistent object itself. 3. Objects that refer to a string which is neither a name, nor a NIC handle. For example, it might be a phone number in admin-c attribute, or it might be 'Gunduz', a string that can't be a NIC handle, as it's longer than 4 letters, nor can it be a name as it has only one word. Another example could be "Mr. Gunduz", which enters this category because "Mr" can't appear in a name of person/role object. Solution: Create a person object for each such reference. Name the object "person: Place Holder Object" and list the object that refers to it in its remarks attribute. Protect it with inconsistent object's maintainer(s). Then update the inconsistent object to refer to the NIC handle of this new place holder person object.
In each case an object is updated, or created, send appropriate notifications (determined by "mnt-by" and "notify" attributes, as with all other updates).
Please note that this proposal does not actually solve the problem of invalid contact information-- rather, it makes the data set more uniform, thus decreases the administration and development time of the whois database.