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. Registries in the Asia/Pacific region are reported to use suffix strings derived from the ISO3166 country codes.
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? Please feel free to ask more questions if this is still in the dark :-) Wilfried. 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... -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------
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
David,
Registries in the Asia/Pacific region are reported to use suffix strings derived from the ISO3166 country codes.
Yes. For primarily historical reasons, APNIC attempted to be more distributed than RIPE, delegating more responsibility to national bodies. The idea was to have a nationally based registry which would handle stuff like handles.
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...
Theoretically speaking: if( $suffix eq "RIPE" ){ `whois -h whois.ripe.net $arg`; } elsif( length( $suffix ) == 2 ){ `whois -h whois.apnic.net $arg`; } else { `whois -h internic.net $arg`; }
And what if you have more registries in one country ?!?
Again, theoretically, this would be an internal issue within the country. One possible solution would be to have a second level (like, oh say, the DNS), e.g., XX1-Y-TV.
I don't think this country code suffix method is a good idea.
Personally, I think the whole idea of handles suck. However, given they seem to be necessary, I tend towards Daniel's idea of using a more DNS-like architecutre.
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"
In the AP region, there are currently 5 registries which allocate person objects, soon to be at least 3 more. The original theory was that APNIC would be using rwhois, thus when a query for an APNIC handle was directed at APNIC's server, it could derive which national NIC to throw the query off to, if such a national NIC existed. Using your proposed approach, you will need to know a priori where each person-object-registering-registry's whois server is located. In a more distributed model than the existing RIPE model, this would not appear to scale well. However, given rwhois is not (in my opinion) ready for production service yet, the APNIC solution is worse.
I don't think we can solve this with education. Again suggestions are welcome!
I feel it is long past time for the architecture of handles to be completely redone. As an off-the-cuff proposal not having thought about this in any great detail, but stealing the general concept from your imperious leader (:-)): Use the DNS. Have handles.net (or somesuch) allocated and allocate subdomains for APNIC (and APNIC's assorted sub-registries, underneath APNIC's subdomain), RIPE, and InterNIC. When you have a handle (say, XX1.AP), the whois server appends .handles.net, does a DNS lookup and gets the IP address of the whois server where the record associated with the handle is stored. The rest is left as an excersize or the reader (so I can just handwave around all the obvious problems (like InterNIC's huge number of handles) :-)). Comments? Regards, -drc
Hi David,
David Conrad writes :
Theoretically speaking:
if( $suffix eq "RIPE" ){ `whois -h whois.ripe.net $arg`; } elsif( length( $suffix ) == 2 ){ `whois -h whois.apnic.net $arg`; } else { `whois -h internic.net $arg`; }
I know, but one exception (Internic) is probably nicer ;-).
And what if you have more registries in one country ?!?
Again, theoretically, this would be an internal issue within the country. One possible solution would be to have a second level (like, oh say, the DNS), e.g., XX1-Y-TV.
OK, but this is something I don't disagree with, I say only: "name of registry should be the same name as the suffix for the nic handle" The name for the registry can easily be a DNS like name ...
Personally, I think the whole idea of handles suck. However,
But we have them right now ... It is still better then getting 100 people with the same name after a query (you know all that Davids ;-)).
I feel it is long past time for the architecture of handles to be completely redone. As an off-the-cuff proposal not having thought about this in any great detail, but stealing the general concept from your imperious leader (:-)):
You might be right here (Exercise for the reader: which part of the paragraph am I talking about ;-))
Use the DNS. Have handles.net (or somesuch) allocated and allocate subdomains for APNIC (and APNIC's assorted sub-registries, underneath APNIC's subdomain), RIPE, and InterNIC. When you have a handle (say, XX1.AP), the whois server appends .handles.net, does a DNS lookup and gets the IP address of the whois server where the record associated with the handle is stored. The rest is left as an excersize or the reader (so I can just handwave around all the obvious problems (like InterNIC's huge number of handles) :-)).
Comments?
No comments (yet). I will keep this proposal in mind. Kind regards, David Kessens
participants (3)
-
David Conrad -
David.Kessens＠ripe.net -
Wilfried Woeber, UniVie/ACOnet