In message <CAKvLzuH7dhj6ti_RW_hqo61BOsXT_7iiihkVs9D_O0M-uPb9uQ@mail.gmail.com> denis walker <ripedenis@gmail.com> 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/g... 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.