Invalid references in the RIPE Database cause unnecessary overhead in Database administration and development of the RIPE Database software. A proposal has been put forward to clean up specific invalid references.
Following approval by the Database Working Group and the LIR Working Group, the following proposal will be applied to:
- TEST Database on Wednesday, 15 January 2003, afternoon (CET)
- RIPE Database on Thursday, 16 January 2003, afternoon (CET)
Proposed solution
Motivation:
References by name and invalid references cause two main problems:
- One reference by name in a single object locks all person and role objects with that name. They cannot be deleted because of referential integrity checks.
- 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:
- 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 a referring inconsistent object and the person or 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 the appropriate remarks and changed attributes to the object to explain the reason for the 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 the 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 the 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 the update.
- 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.
- Objects that refer to a string which is neither a name, nor a NIC handle
For example, it might be a phone number in the "admin-c" attribute, or it might be "Gunduz", a string that cannot be a NIC handle, as it is 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." cannot appear as a name in a person or 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 the 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 where an object is updated or created, notifications will be sent to the appropriate e-mail addresses (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. It makes the data set more uniform, which decreases the administration and development time of the RIPE Database.