[address-policy-wg] 62.222.0.0/15

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:         inoc at carrier1.com
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 <address-policy-wg-bounces at ripe.net> On Behalf Of Ronald F. Guilmette
Sent: Wednesday, October 9, 2019 2:28 PM
To: address-policy-wg at ripe.net
Subject: Re: [address-policy-wg] 62.222.0.0/15

In message <51955AEB-477D-4020-B6CD-67B8605BF0AD at clouvider.co.uk>,
Dominik Nowacki <dominik at clouvider.co.uk> 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.