“cooling” down, pun to the network name intended, is recommended before publicly accusing someone of any wrongdoing. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net<mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 9 Oct 2019, at 06:29, David Guo via address-policy-wg <address-policy-wg@ripe.net> wrote:  IE-COOLWAVE-20010321 use time machine and go back to year 2001 ________________________________ From: address-policy-wg <address-policy-wg-bounces@ripe.net> on behalf of Jacob Slater <jacob@rezero.org> Sent: Wednesday, October 9, 2019 1:00:56 PM To: Ronald F. Guilmette <rfg@tristatelogic.com> Cc: address-policy-wg@ripe.net <address-policy-wg@ripe.net> Subject: Re: [address-policy-wg] 62.222.0.0/15 According to https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran..., this appears to have been a transfer, not a new allocation. Jacob Slater On Wed, Oct 9, 2019 at 12:30 AM Ronald F. Guilmette <rfg@tristatelogic.com<mailto:rfg@tristatelogic.com>> wrote: I didn't realize till now that RIPE NCC was still giving out IPv4 /15 blocks as recently as August. Now that I know, may I have one too please? ================================================================= inetnum: 62.222.0.0 - 62.223.255.255 netname: IE-COOLWAVE-20010321 country: IE org: ORG-CCL78-RIPE admin-c: DW5409-RIPE tech-c: DW5409-RIPE status: ALLOCATED PA mnt-by: mnt-ie-coolwave-1 mnt-by: RIPE-NCC-HM-MNT created: 2019-08-20T11:55:01Z last-modified: 2019-08-20T11:55:01Z source: RIPE

In message <TY2PR0101MB334291F09C6FB3C44F06A303C5950@TY2PR0101MB3342.apcprd01.prod.exchangelabs.com>, David Guo <david@xtom.com> wrote:

IE-COOLWAVE-20010321

use time machine and go back to year 2001

Mine's in the shop, having some valves replaced. Can I borrow your's? But seriously folks, if 62.222.0.0/15 is just a merge of its two constituent /16 blocks, then why is it that the data base contains -lots- of historical records about 62.223.0.0/16, going all the way back to 2007-06-28 and yet it contains -no- historical records whatsoever regarding 62.222.0.0/16 ?

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? With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969<tel:08750969>. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse@clouvider.net<mailto:abuse@clouvider.net> of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 9 Oct 2019, at 06:37, Ronald F. Guilmette <rfg@tristatelogic.com> wrote: In message <CAFV686eC55sR4vd4iB_ykRmf9ddgm1=pOxsNGSVqji+fD08VtQ@mail.gmail.com>, Jacob Slater <jacob@rezero.org> wrote: According to https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran..., this appears to have been a transfer, not a new allocation. I guess that I will have to speak to my friends in the DB working group about that, because there is *no* indication of this whatsoever in either the current -or- the historical records for the 62.222.0.0/15 block, specifically. The only historical record on file for this block is as follows: ======================================================================== % Version 1 (current version) of object "62.222.0.0 - 62.223.255.255" % This version was a UPDATE operation on 2019-08-20 13:55 inetnum: 62.222.0.0 - 62.223.255.255 netname: IE-COOLWAVE-20010321 country: IE org: ORG-CCL78-RIPE status: ALLOCATED PA mnt-by: mnt-ie-coolwave-1 mnt-by: RIPE-NCC-HM-MNT created: 2019-08-20T11:55:01Z last-modified: 2019-08-20T11:55:01Z source: RIPE

Why don't you do some search? https://web.archive.org/web/20191009065654/https://bgpview.io/prefix/62.222.... 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@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@ripe.net> On Behalf Of Ronald F. Guilmette Sent: Wednesday, October 9, 2019 2:28 PM To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 62.222.0.0/15 In message <51955AEB-477D-4020-B6CD-67B8605BF0AD@clouvider.co.uk>, Dominik Nowacki <dominik@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.

Hi, it doesn't show up in the versions because the transfer deleted the old item and created a new one. - Cynthia On Wed, 9 Oct 2019, 09:14 Ronald F. Guilmette, <rfg@tristatelogic.com> wrote:

In message < TY2PR0101MB33421E6796B2013776568E52C5950@TY2PR0101MB3342.apcprd01.prod.exchangelabs.com>,

David Guo <david@xtom.com> wrote:

...

Why don't you do some search?

I did. I do. I am. I have!

Please excuse me for having foolishly tried to obtain actual authoritative information from the actual RIPE WHOIS server, rather than from a Wayback Machine (archive.org) copy of something that appeared on the bgpview.io web site.

Regardless of what that other non-authoritative source of information may say, may I ask you to please tell me what *you* see when *you* perform the following two commands?

whois -h whois.ripe.net -- "--list-versions 62.222.0.0/15" whois -h whois.ripe.net -- "--show-version 1 62.222.0.0/15"

Maybe I need new glasses, but I'm not seeing the year 2002 mentioned in the outputs of these two commands.

Maybe I'm just doing it wrong. Do I need to try using negative numbers as arguments to the --show-version option?

Does that option accept imaginary numbers as arguments?

Regards, rfg

You see the year mentioned in the netname generated during the transfer by RIPE (always using original date) IE-COOLWAVE-20010321 and in RIPEstat: First ever seen announced by AS8918 <https://stat.ripe.net/AS8918>, on *2001-03-24 00:00:00 UTC*. Kind regards On 09/10/2019 10:22, Piotr Strzyzewski via address-policy-wg wrote:

On Wed, Oct 09, 2019 at 12:14:23AM -0700, Ronald F. Guilmette wrote:

...

Regardless of what that other non-authoritative source of information may say, may I ask you to please tell me what *you* see when *you* perform the following two commands?

whois -h whois.ripe.net -- "--list-versions 62.222.0.0/15" whois -h whois.ripe.net -- "--show-version 1 62.222.0.0/15"

Maybe I need new glasses, but I'm not seeing the year 2002 mentioned in the outputs of these two commands.

Maybe I'm just doing it wrong. Do I need to try using negative numbers as arguments to the --show-version option?

Does that option accept imaginary numbers as arguments? Start from reading some documentation.

https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...

"It is possible to query the history of operational data objects that still exist."

It has been already pointed out that this /15 could have been part of something bigger or, quite contrary, part of two separate /16 or even something completely different, which means that the original object could be non-existent. Checking this out is left as an exercise for the reader.

Piotr

-- Thomas BRENAC https://www.brenac.eu +33686263575 Certified IPv4 Broker by RIPE NCC, ARIN, APNIC and LACNIC The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. This message has been sent as a part of discussion between BRENAC EURL and the addressee whose name is specified above. Should you receive this message by mistake, we would be most grateful if you informed us that the message has been sent to you. In this case, we also ask that you delete this message from your mailbox, and do not forward it or any part of it to anyone else. Thank you for your cooperation and understanding. We puts the security of the client at a high priority. Therefore, we have put efforts into ensuring that the message is error and virus-free. Unfortunately, full security of the email cannot be ensured as, despite our efforts, the data included in emails could be infected, intercepted, or corrupted. Therefore, the recipient should check the email for threats with proper software, as the sender does not accept liability for any damage inflicted by viewing the content of this email. The views and opinions included in this email belong to their author and do not necessarily mirror the views and opinions of the company. Our employees are obliged not to make any defamatory clauses, infringe, or authorize infringement of any legal right. Therefore, the company will not take any liability for such statements included in emails. In case of any damages or other liabilities arising, employees are fully responsible for the content of their emails.

Hank, IMHO best and quickest option is to check http://stat.ripe.net, for more detailed history results use your LIR account login. Uros On Wed, Oct 9, 2019 at 9:16 PM Hank Nussbacher <hank@efes.iucc.ac.il> wrote:

On 09/10/2019 09:58, David Guo via address-policy-wg wrote:

David,

Thanks. But shouldn't one be able to query something like this from some xxx.ripe.net site rather than depending on archive.org or bgpview.io?

-Hank

...

Why don't you do some search?

https://web.archive.org/web/20191009065654/https://bgpview.io/prefix/62.222....

...

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@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

On Wed, Oct 9, 2019, at 07:37, Ronald F. Guilmette wrote:

I guess that I will have to speak to my friends in the DB working group about that, because there is *no* indication of this whatsoever in either the current -or- the historical records for the 62.222.0.0/15 block, specifically.

Probably a less specific.... When a less specific is splitted for transfer, the transferred chunk (didn't check for the remaining ones, but I suppose it's the same), has the "created date" of the transfer, but the date in the netname retains the date of the initial allocation. -- Radu-Adrian FEURDEAN

On Wed, Oct 9, 2019, at 09:01, Ronald F. Guilmette wrote:

I thought that we were discussing something that had been -aggregated-, not split.

Mea culpa, Still, the logic remains the same. The "created" field indicated when the record has been created (split, aggragation or transfer being reasons to create a new record), not when the space has been allocated. Allocation date does not have a field in its own, but that date is contained in the main block's "netname". -- Radu-Adrian FEURDEAN

On Wed, Oct 9, 2019 at 11:04 AM Garry Glendown <garry@nethinks.com> wrote:

Could we please stop these "conspiracy theory" discussion?

+1

On Wed, Oct 09, 2019 at 01:04:29PM -0700, Ronald F. Guilmette wrote:

...

Could we please stop these "conspiracy theory" discussion? In essence, the initial question inferred that RIPE is still handing out IPV4 outside of current policies, which I'm pretty sure they don't.

I'm sorry to learn that my modest attempts at wry humor have fallen so flat over on the Left Side of the Pond.

Of course, NCC has not been giving out /15 blocks. (According to what I was reading just yesterday, NCC doesn't even have any such to give!) But if you look at the data base record that I posted, that is clearly the implication that would be derived from a straightforward reading of the plain text of the record in question:

inetnum: 62.222.0.0 - 62.223.255.255 ... created: 2019-08-20T11:55:01Z

This is the same straightforward conclusion like the one that the speed limit is 35 km/h (and not mph) just because the road signs looks similar both in UK and France. Once again, be so kind and read the documentation. The created attribute means something completely different. Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland