In message <cakvlzuh7dhj6ti_rw_hqo61bosxt_7iiihkvs9d_o0m-upb...@mail.gmail.com>
denis walker <[email protected]> wrote:
>Why are you trying to reinvent the wheel?
I'm not "trying". My code is already done and tested and working.
>Why don't you use the RIPE GRS service?
If it's so swell and accurate, then why haven't you sold it or given it to
IANA and why haven't you convinced them to use it as a replacement for their
evidentally broken port 43 WHOIS server?
Look denis, I understand that you are proud of your baby, and I'm sure
rightfully so, but there are multiple answers to your question "Why
doesn't RFG use my beautiful baby?"
First and foremost, I had a problem to solve and I set forth to solve it,
which I did. At the time, I was totally unaware of this RIPE GRS service
that you're on about. (Not that I necessarily would have used it even if
I had known about it. I'm not too sure I would have. See below.)
If I didn't know about it, then whose fault is that? Sure. If it makes you
feel superior you can just be smug and say that RFG is an ignorant idiot
and that's why he didn't know about it. But I could then retort and say
that you have done a less than adequate job of publicising the RIPE GRS
Service. Who is right and who is going to win this pissing match? Arguably
we're both right. So let's just pretend that we already had this pointless
pissing match, that neither us us won, and that everyone else on this list
was bored to tears by the whole thing and begged us all to take it off list.
So let's just move on shall we?
More to the point, and regardless of whether I should have found out about
your poorly publicised RIPE GRS Service or not, or whether you should have
done more to publicise it, there are other reasons why I might not have
elected to use the RIPE GRS Service even if I had known about it:
*) I abhor becoming dependant upon other people's code and/or upon other
people's willingness to fix bugs and/or upon other people's lack of
enthusiasm for writing documentation. When I google for "RIPE GRS
service" the first thing that comes up is this:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/glossary/global-resource-service-grs
Swell. A page describing something in sort of vague terms and which
provides exactly -zero- links for the benefit of people who want to
learn more about this wonderful thing. Is this a joke of some kind?
If so, then I confess that I don't get it.
The third google hit is a link to something on github. Uh oh! Red
flag right there. So in order to use your magic fu, I need to download,
compile (and perhaps port to FreeBSD) your code before I can use your
magical solution. OH! AND WAIT! I guess that I also have to install
Java[tm], which I trust about as far as I can throw it. Marvelous.
Because I just didn't already have enough to do today, and I never
seem to have quite enough security bugs on my main server/workstation,
so I definitely want to drop whatever else I was doing and install
Java.
Did I mention that I don't even speak Java, and that thus, extending
your code or integrating it with my own is pretty much a non-starter
for me?
*) The first order things that I want from, and that I am getting from the
daily RIR "stats" files is/are *not* full WHOIS infornmation. I know
where to get THAT information when & if I need it, i.e. direct from
the various RIR WHOIS servers. What I want from, and what I am almost
effortlessly getting from the daily stats files is:
*) Lists of all IPv4/IPv6/ASN space blocks that have been assigned
to, or transferred to each respective RIR.
*) Lists of all IPv4/IPv6/ASN space blocks that have been assigned
by each respective RIR to its resource members.
This is *not* WHOIS information per se. And for what I was trying to
accomplish I didn't need full WHOIS information. I only needed what
I have identified just above, which is vastly simpler.
Now, let's look at what your de luxe RIPE GRS service provides:
https://labs.ripe.net/author/denis/the-ripe-global-resource-service/
"The primary goal of this service is to provide information on
global Internet resources from all the RIRs and some routing
registries (listed below). This involves inetnum and inet6num
objects, representing IPv4 and IPv6 address space, and aut-num
objects, representing Autonomous System Numbers (ASN). Other
operational objects like route and route6 and additional supporting
objects, such as person and role , are also included for some sources."
So basically, you're demanding to know why I'm not using your pride
and joy, and you're astonished that I'm not using something that
provides a glorious wealth of information that I simply do not need
and that I would have to expend extra labor to filter out in order to
get just that minimal information that I *do* actually need. Is that
about the size of it?
If I have failed to clarify why I might not have elected to use your
marvelous and exceedingly lovely GRS thing then I don't know what else
to say. The RIPE GRS Service provides vast amounts of information,
most of which is totally irrelevant to my actual and minimalist needs.
But let's set that annoying little fact aside for a moment. Please
tell me how I can quickly and efficient extract from the RIPE GRS
Service a complete list of all IP blocks that have been allocated
*directly* from any & all RIRs, worldwide, to any of their resource
members. Once you have done that, then please explain how obtaining
such lists from the RIPE GRS Service is either more efficient or for
any other reason is preferable to obtaining the exact same information
from the daily RIR stats files.
No hurry. I'll wait.
>It will tell you exactly where any RIR administered
>address space is as of yesterday.
So will the daily stats files. What's your point?
I can get the daily stats files using just WGET or CURL, both of which are
already installed on my system, and I DO NOT have to either download or
rely on anybody else's mystery code and I DO NOT have to install any
bleedin' suspect Java interpreter, and I DO NOT have to waste time figuring
out which exact version of the Java interpreter is compatible with your
code, and I DO NOT thenceforth and forever have to worry about keeping that
Java interpreter up-to-date with the latest security patches.
I understand that you are very proud of the hammer you've built. Really I do.
But the fact that you've built a very beautiful & shiny hammer does not render
every problem in the world as a nail. My needs were and are perfectly met
by the modest amount of Perl code and shell scripts that I wrote... code
that I wrote and that I can now extend, maintain, and integrate with my
other tools because unlike Java, I do actually speak Perl.
>The mirrored RIR databases are
>updated daily by the RIPE NCC. It is probably more accurate and more
>reliable than any home built work around.
No.
I have made this point already. The daily RIR stats files are updated
by the RIRs themselves "daily". If you are being fed data by the RIRs
that is more up-to-date and (thus) more accurate than that, then please
do tell me where I can sign up for that "early update" service from the
five RIRs also. Otherwise the data that is present in your GRS thing is
no more accurate than what I have, and may possibly be even less so.
Regards,
rfg
P.S. It's up to you, of course, but I do think that in future your time
would be more productively spent in reviewing your own design decisions,
rather than trying to second guess or "Monday morning quarterback" other
people's design decisions. Their needs may not be your needs, and their
goals may not be your goals.
