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

Reply via email to