Why don't you do some search? https://web.archive.org/web/20191009065654/https://bgpview.io/prefix/62.222.0.0/16#whois
inetnum: 62.222.0.0 - 62.223.255.255 org: ORG-CB2-RIPE netname: NL-COOLWAVE-20001027 country: NL admin-c: DW581-RIPE tech-c: DW581-RIPE tech-c: SM7902-RIPE status: ALLOCATED PA notify: [email protected] mnt-by: RIPE-NCC-HM-MNT mnt-by: IBIS-MNT mnt-routes: CARRIER1-MNT created: 2002-07-25T12:34:10Z last-modified: 2017-07-10T10:10:24Z source: RIPE created: 2002-07-25T12:34:10Z Regards, David -----Original Message----- From: address-policy-wg <[email protected]> On Behalf Of Ronald F. Guilmette Sent: Wednesday, October 9, 2019 2:28 PM To: [email protected] Subject: Re: [address-policy-wg] 62.222.0.0/15 In message <[email protected]>, Dominik Nowacki <[email protected]> wrote: >How about if this wasn’t full allocation transfer ? You are making a >query about the particular exact size of the block so it wouldn’t show? > >Also, baffled that you have the guts to continue on this quest >following an obviously false accusation that you started it with? Sir, I do think you have me mixed up with someone else. I have made no "acccusation" against anyone for anything. I think that you may perhaps be mistaking my desire to understand why the WHOIS data base queries sometimes (often?) yield results which are both surprising and entirely non-intutive, as I have just amply illustrated, I think, for something which is somehow accusatory towards some resource holder. I do think that the evidence shows that there is at least some recognizable possibility that the data base query mechanisms may be operating in a less than ideal manner, and thus producing less than ideal results. But even if that is verified to be true, then my only "quest" would be to try to get the NCC folks to fix the broken data base functionality... a laudable goal which I would hope would garner nearly universal support. Regards, rfg P.S. Perhaps I am now a victim of my own success. I am aware, as are others, I guess, that over time I have been rather successful at ferreting out instances in which various IPv4 blocks somehow ended up in the Wrong Hands. But I hope that everyone will still give me the benefit of the doubt, regadless of that, and allow for the possibility that when I raise an issue about a data base quirk, I really am only looking to discuss the data base quirk, and that I have neither any hidden meaning nor any hidden agenda. Of couse, if the simple example I posted is *not* merely a result of either my misunderstanding of the data base access methods (most likely explanation) -or- a result of an actual obscure failure of the data base or its access methods, then the only possibility left is that some party did indeed get a /15 in August of 2019, in clear contravention to established RIPE policy at the time. This is so obviously unlikely however that it can be almost entirely discounted as even being a possibility. So eiher I'm confused about how I am interpreting the data or else the data base access methods are giving confusing (and misleading?) responses. In either case, I'd like to see the problem eliminated.
