Inconsistent NIC handles

Dear Wilfried, Janos,

> Wilfried Woeber, UniVie/ACOnet writes :
>
>   Dear Janos!
> 
> >Theoretically the NIC handle is supposed to uniquely identify the person.
> 
>   More precisely: ... a uniquely assigned Handle is supposed to...
> 
> >The problem I noticed is that somebody (inadvertently) registered a person
> >with an Internic-type NIC handle (i.e. without the "-RIPE" suffix) in the
> >RIPE database. 
> 
>   This is a perfectly legal situation, as long as the person being
>   described has a unique handle assigned already, probably from the
>   InterNIC.
> 
>   Obtaining a unique handle from the RIPE-NCC (of the form xyz999-RIPE)
>   and then registering the person object *without* the "-RIPE" suffix
>   string is clearly an error.
> 
>   The overall scheme is that the InterNIC has in the past assigned, and
>   continues to do so, handles of the form xyz999. Every other source of
>   unique handles assignes strings of the form xyz999-suffix, the suffix
>   being unique in itself. The string "-RIPE" is used for the RIPE Handles.

The story is correct but we keep the problem that we *cannot* find out in
a reliable way if a handle without the '-RIPE' suffix that comes from
another database is assigned to the same person or is an error. Any ideas
for a solution are welcome!

>   Registries in the Asia/Pacific region are reported to use suffix strings
>   derived from the ISO3166 country codes.

This is true. And this makes it even more difficult since you cannot find
out anymore from the suffix in which database to look for a certain
person... And what if you have more registries in one country ?!? I don't
think this country code suffix method is a good idea. I would appreciate
if this could be changed (Randy ?!?) to the policy "the suffix is
the source name of the registry were the person object is registered"

> >The result is an inconsistency between the two databases
> >(RIPE and Internic). One gets different answers, depending on whom one asks the
> >question.
> 
>   Not necessarily so! The IneterNIC is expected to accept handles
>   assigned by other regsitries interchangably when importing data
>   (objects) from other sources. 
> 
>   Btw, has this been tried by anyone recently?

Yes, and it didn't succeed. It was again asked to change this but nothing
happened so far...

> PS: If you could point out the affected objects we could possibly find
>     out what went wrong or if there is really a flaw in the logistics...

The person who did this informed. The problem is not in the object. The
problem is that many people are used to the format of the Internic nic
handles and just think that a nic handle should look like that ...
This accident is not the first one and I am quite sure that there are
more of these objects in the database.
I don't think we can solve this with education. 
Again suggestions are welcome!

Kind regards,

David Kessens