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/db-wg@ripe.net/
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 ]