[lir-wg] Re: Updated proposal for clean-up of references by name

[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.
>