Hi,

I would like to support this initiative and request that it gets implemented.

Recently we developed a platform for IP Transfers where we provide a lot of data to our customers to help them do their due diligence before deciding to make a transfer of IP addresses. We collect ripe historic whois, apnic and arin whowas among other sets of data.

We've realized in the past 6 months, since our platform went live, that a lot of our customers value this information and find it extremely useful when deciding which IP block they want to transfer.

However, we can not collect this data for our customer's due diligence if the resource is deleted (and re-created) due to a transfer or other events.

So, you have my support to make this data available either through the current ripe historic whois tool or using a whowas tool, whether it is public (as APNIC's) or one that requires registration (as ARIN's).

I can have dozens of customers confirm this is useful data, let me know if I should contact them and tell them to voice their opinion on this mailing list or whether my voice is enough at this time :)

cheers,

elvis

On 10/1/20 5:07 AM, ripedenis--- via db-wg wrote:
Hi Ronald

You are mistaken :) The query string can be a single IP address or CIDR or a range. And the range doesn't even need to be an exact matching range. So if you search for:

x.y.0.0 - x.y.0.100

and the actual object in the database is:

x.y.0.0 - x.y.0.255

it will still return this database object. As long as the search string is encompassed by the actual object.

cheers
denis

co-chair DB-WG

On Thursday, 1 October 2020, 04:42:38 CEST, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:


On a related but different point...


>Let me give some background on this. Objects in the database are accessed b=
>y their primary key (pkey). In the case of an INETNUM object, for instance,=
>this is an address range...


Actually, not to quibble or anything, but unless I'm mistaken, the query
string has to be either a single IP address or a single CIDR.

I only mention this because some allocations are what I would call
"funny", i.e. they are not expressible as a single CIDR.


Regards,
rfg