Who says the databases have to be merged to be mirrored?
So ARIN can spend about one /19 registration fee on a server to send over
to one of the other registries, and can run a mirror server at that remote
location. They'd use SSH/scp so as to be sure nobody from the other
registry sniffed their packets and stole the secrets of their software.
Maybe I'm missing something...it just doesn't seem like rocket science to
me.
Who says the databases have to be merged to be mirrored?
as a user of these databases, i want to perceive it all as one database
where i can get my question answered in a single query.
randy
> Who says the databases have to be merged to be mirrored?
as a user of these databases, i want to perceive it all as one database
where i can get my question answered in a single query.randy
evidently Randy sez.
Who says the databases have to be merged to be mirrored?
as a user of these databases, i want to perceive it all as one database
where i can get my question answered in a single query.evidently Randy sez.
read again. i posited an end-user requirement, not how to implement it.
randy
That's a totally different issue than mirroring for redundancy. Current
trends (Internic/ARIN database split) seem to be moving in the opposite
direction.
No, you posited an end-user *request*.
Since you are dealing with multiple firms, none of whom are required to
cooperate, that's where it begins and ends.
Jon,
So ARIN can spend about one /19 registration fee on a server to send over
to one of the other registries, and can run a mirror server at that remote
location.
Why put it at a another registry? Why not put it off an exchange? Or why
not allow ARIN members to mirror the database? I'm sure NSI would love to
sell the software... (:-)).
Maybe I'm missing something...it just doesn't seem like rocket science to
me.
I guess it is a question of usability (as Randy pointed out). I personally
think the fact that people have to know what prefixes have been allocated
to whom before they can find out what prefixes have been allocated to whom
is _really_ broken. It used to not matter too much (other than the
aesthetic unpleasantness of it all), but given the increase of spam and the
use of the registry database "system" to figure out who to scream at, the
fact that the registry database "system" sucks is beginning to matter more
and more.
Yes, this is a different issue than merely mirroring a single registry's
database.
Regards,
-drc
>So ARIN can spend about one /19 registration fee on a server to send over
>to one of the other registries, and can run a mirror server at that remote
>location.Why put it at a another registry? Why not put it off an exchange? Or why
not allow ARIN members to mirror the database? I'm sure NSI would love to
sell the software... (:-)).
Just figuring the various registries would be willing to exchage
colocation services with each other at no charge. I guess if you have
expense accounts and such, put the mirrors all over.
I guess it is a question of usability (as Randy pointed out). I personally
think the fact that people have to know what prefixes have been allocated
to whom before they can find out what prefixes have been allocated to whom
is _really_ broken. It used to not matter too much (other than the
Wouldn't it make more sense if registry data was handled similar to DNS?
i.e. if you had to know that to resolve lewis.org, the DNS server to ask
was kashmir.fdt.net, DNS would be worthless. First your resolver asks one
of the root-servers, and they tell you who to ask. Why not have a root
registry...so when I do a whois of 200.27.89.0, I don't have to figure out
or guess which registry to ask. I just ask (maybe rs.iana.org) and it
tells my whois client which registry to ask...and the client (transparent
to me) asks the appropriate registry and gives me the answer I was looking
for.
Hi,
Wouldn't it make more sense if registry data was handled similar to DNS?
Right. As I said previously, its just a small matter of programming (e.g.,
see rwhois).
There are a couple of issues, however:
a) if the registry database is used to provide contact information to help
resolve network problems (a stretch, I know :-)), and the only way you can
obtain the contact information is via the network, then if the network is
broken to the place you need to get to to find the contact information...
(yes, caching and seconarying can solve this issue)
b) quality assurance -- how much can you trust the people you delegate
authority to manage the data
(yes, strong QA control can solve this issue)?
My personal past experience has shown both of these to be a problem.
Regards,
-drc
And they're a problem with the current WHOIS which is used for DNS
registrations, but we still use WHOIS to look up domain information. I say,
let's put the thing into place, because it IS a workable (if not perfect)
solution, and we can always make improvements.
While not the most elegant solution to the problem, anyone can modify
their whois client to lookup via multiple whois servers.
The more correct solution would be for ARIN to move to a RIPE-ish whois
server.
Then again, why should ARIN use industry standard, public domain
software, when they can use NSI's proprietary system? Obviously, RIPE,
APNIC, RIPN, MCI-RR, RADB, CA*NET, 6BONE, etc. are all fools for using
that darn free stuff...
Anyone who uses the RADB can attest to how well the IRR databases share
information, both with each other and with daily dumps. Too bad NSI and
now ARIN don't want to play nice with the other children.
Tip of the day: You can make a "normal" whois client act more like a
RIPE whois client by putting a -- before the RIPE-specific options.
Stephen
David R. Conrad wrote:
The more correct solution would be for ARIN to move to a RIPE-ish whois
server.Then again, why should ARIN use industry standard, public domain
software, when they can use NSI's proprietary system?
Probably because the database would need to be converted and the ARIN
staff have their hands full already with starting up a new organization
and a new network in new offices.
Too bad NSI and
now ARIN don't want to play nice with the other children.
If you make a good case for ARIN adopting the RIPE software and database
format then I'll present it to the rest of the Advisory Council. So tell
me, what are the pros and what are the cons of switching to the RIPE
format? How much lead time will network operators need to make sure
automated systems don't break?