[lir-wg] Re: Updated proposal for clean-up of references by name
- Date: Tue, 14 Jan 2003 12:54:13 +0100
[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.
>
