This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Inconsistent NIC handles
- Previous message (by thread): Inconsistent NIC handles
- Next message (by thread): Inconsistent NIC handles
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
David Conrad
davidc at apnic.net
Mon Oct 9 15:41:58 CET 1995
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
- Previous message (by thread): Inconsistent NIC handles
- Next message (by thread): Inconsistent NIC handles
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]