NWI reviews: NWI-2 displaying history for DB objects where available
Dear Colleagues This is another action point that has been open for 4 years. We either need to progress it or cancel it.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005240.html It is basically asking for full history of existing and deleted resource objects. In the link above on this NWI it mentions some doubt over the value of full history. So the main questions are, -"is full history more useful than partial history?" -"is history of deleted objects, that don't currently exist in the database, useful?"If so then I don't see any reason not to provide it. Let me give some background on this. Objects in the database are accessed by their primary key (pkey). In the case of an INETNUM object, for instance, this is an address range. Internally to the database all objects also have an object ID. Each time an object is modified a new instance of the object is created in the database with the same pkey and object ID. (Other meta data is updated to keep the sequence of changes.) When an object is deleted and re-created with the same pkey, the new object has a new object ID. Then the sequence of changes continues with this new object. When the RIPE NCC proposed to make history of objects available an arbitrary decision was made to present the history of a currently available object with all instances having the same object ID. In other words the history presented only went back as far as the creation of the current sequence of object modifications. The object may have existed before this sequence and been deleted and re-created. That part of the history is not available by the current query mechanism. But of course that history does exist in the database. It is not difficult for the software to present the full history of an object based on the pkey, no matter how many times it has been deleted and re-created. The decision to only give history back to the most recent deletion was an arbitrary, low hanging fruit, option to get a service up and running quickly. It has just stayed that way ever since. Your comments are appreciated... cheersdenis co-chair DB-WG
FYI, when APNIC implemented "WHOWAS" we deliberately walk over deletions to carry history backward to prior state. Whowas is implemented in RDAP, its meta state over RDAP representation of the information but the underlying information comes from Whois updates. We also have a view inside APNIC that the convergence of RDAP and whois as to their information is very important. Having history terminate in delete inside Whois makes this specifically hard, in this space. That said, I understand privacy concerns behind some of the reasoning here. I think (personally) that moving from "person" objects to Role objects and Org objects makes this moot, I do not regard corporate entity privacy as very compelling. But, we do have to respect legal requirements. cheers -George On Wed, Sep 30, 2020 at 10:24 PM ripedenis--- via db-wg <db-wg@ripe.net> wrote:
Dear Colleagues
This is another action point that has been open for 4 years. We either need to progress it or cancel it. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005240.html
It is basically asking for full history of existing and deleted resource objects. In the link above on this NWI it mentions some doubt over the value of full history. So the main questions are, -"is full history more useful than partial history?" -"is history of deleted objects, that don't currently exist in the database, useful?" If so then I don't see any reason not to provide it.
Let me give some background on this. Objects in the database are accessed by their primary key (pkey). In the case of an INETNUM object, for instance, this is an address range. Internally to the database all objects also have an object ID. Each time an object is modified a new instance of the object is created in the database with the same pkey and object ID. (Other meta data is updated to keep the sequence of changes.) When an object is deleted and re-created with the same pkey, the new object has a new object ID. Then the sequence of changes continues with this new object.
When the RIPE NCC proposed to make history of objects available an arbitrary decision was made to present the history of a currently available object with all instances having the same object ID. In other words the history presented only went back as far as the creation of the current sequence of object modifications. The object may have existed before this sequence and been deleted and re-created. That part of the history is not available by the current query mechanism. But of course that history does exist in the database. It is not difficult for the software to present the full history of an object based on the pkey, no matter how many times it has been deleted and re-created. The decision to only give history back to the most recent deletion was an arbitrary, low hanging fruit, option to get a service up and running quickly. It has just stayed that way ever since.
Your comments are appreciated...
cheers denis
co-chair DB-WG
In message <2054871960.332293.1601468662795@mail.yahoo.com>, "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk> wrote:
This is another action point that has been open for 4 years. We either need= to progress it or cancel it.https://www.ripe.net/ripe/mail/archives/db-wg/= 2016-May/005240.html It is basically asking for full history of existing and deleted resource ob= jects. In the link above on this NWI it mentions some doubt over the value = of full history. So the main questions are,=C2=A0-"is full history more use= ful than partial history?"=C2=A0-"is history of deleted objects, that don't= currently exist in the database, useful?"If so then I don't see any reason= not to provide it.
Please put me down as ALWAYS being in favor of MORE information. When doing research, less is never more. 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
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. cheersdenis 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
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
participants (4)
-
Elvis Daniel Velea -
George Michaelson -
ripedenis＠yahoo.co.uk -
Ronald F. Guilmette