Adding nic handles to contact objects without one

Dear all,

During the month of February the RIPE NCC, at the RIPE Database working group's request after the RIPE 32 meeting in Amsterdam, put out a proposal to add automatically generated nic handles to existing person objects that do not currently have one.

Some other unrelated issues have caused me to not follow this up appropriately. I am sorry for that.

In order to resume (and hopefully swiftly conclude) this issue, I will use the rest of this message to summarize the state of discussions.

I would like to ask for a 10 day discussion period after which I will summarize the conclusion to the list and have the Database group take whatever action is agreed to.

Summary:

The initial proposal called just for the addition of an automatically generated nic handle to person and role objects which currently do not have one.

This would be done using the same automatic procedure used by the Database software when a user request an AUTO nic handle. That is, the database takes up to 4 initials from the name, looks for the highest exisiting number of a nic handle in the sequence of nic handles with the same initials, generates a new number and adds the suffix "-RIPE".

Input received discussed if we should use the opportunity and try to modify some database objects that reference person and role objects by name instead of nic handle as is required now in the RIPE Database.

These are two separate issues. The first one could be approved without the second one.

The first one alone brings old objects up to date to current specifications, simplifies the prorammers life and enables further steps to increase the DB's consistency. In my personal opinion it is a Good Thing.

The main advantage of the second part is that:

 - References by nic handle are less ambiguous than references by name since the DB ensures that there are no duplicate nic handles whereas there is no reason why two persons can't have the same name.

 (Note: currently there are around 30 duplicate nic handles in the RIPE DB due to legacy objects from the past and bugs in past releases of the software. This problem is being addressed in the context of the RIPE DB consistency project. There will be an extensive report on the progress of this project in the coming RIPE meeting in Vienna).

Doing this doesn't solve all the problems, naturally, and may have some problems as itemized below:

- If the reference by name is to a name for which more than one object exists then there is an ambiguity that can't be handled automatically. The solution to this requires intervention by the referencing object's owner. This will be handled by the DB consistency project.

- If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community.

- There is a chance that a person/role object with a refenced name exists and is unique but is not the one that created the referencing object. Eg. if I created an inetnum object in 1991 but then deleted my person object and then my twin ghost registered in the DB and created some new objects: should the original inetnum object (still in the database) be linked to my twin ghost (who probably doesn't know anything about it)? If this issue is seen as a heavy one then no name references can be modified to references by NIC handle automatically, unless an exhaustive search of the DB update logs is performed (and even then, there is no guaranteed result).

I think summarizes the state of affairs.

Please give your input as soon as possible so that a conclusion can be reached.
If possible, address the original and the extension proposal separately.

Thanks,

Joao Damas
RIPE DB Group Manager
RIPE NCC