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