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
