Adding nic handles to contact objects without one (72 chars/line)

Thou shall not send vi docs directly on a mail!

At people's request here goes the mail again with sorter lines.

Regards,
Joao

------- Include message ------

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 this 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