Subject: [regext] News of draft-ellacott-historical-rdap?

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2017 12:04:17 +0100

draft-ellacott-historical-rdap seems cool and already has running code
at APNIC. But it is also dangerous, since you can no longer erase data
(it is mentioned in the Sceurity Considerations section).

It was briefly discussed at IETF 99 in Prague
<https://datatracker.ietf.org/meeting/99/materials/minutes-99-regext/>
but nothing on the list, and it expires in one month. Is there still
some interest?

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 28 Nov 2017 14:50:48 +0100

> but nothing on the list, and it expires in one month. Is there still

Even if outside of protocol design I would be interested to learn more
about use cases,
especially for a RIR.
In the sense that, as soon as such a service/interface exists there will
be people,
in commercial and non commercial endeavours that will "siphon" out this
data
to provide it in other services.

Not erasing data that could be in part considered as Personal
Information would
go against a lot of laws, especially now in Europe.

-- 
  Patrick Mevzek

---

From: Byron Ellacott <[email-masked]>
Date: Tue, 28 Nov 2017 23:31:35 +0000

Hi,

> On 28 Nov 2017, at 11:50 pm, Patrick Mevzek <[email-masked]> wrote:
> 

The draft is not intended to require that data is never erased.  As with all things RDAP, local legislative and policy requirements direct implementation choices, and where entities have a “right to be forgotten” a service provider may choose an approach to handle the situation.  Here is a non-exhaustive list of options:

 - Remove the record entirely for the affected period, returning only positive assertions of data that is acceptable to present.
 - Omit erased data from presented records, potentially returning only that the object existed at a particular time frame in a different form to other time frames, without specifying how.
 - Replace sensitive data with placeholders or dummy data indicating that a value has been protected, or add a notice to that effect.

And, as this is an RDAP extension, the RDAP authn/authz mechanism may be used to protect historical data from casual access.

I would be delighted to hear of any third parties making use of APNIC’s currently operating history service, particularly those who previously would have been regularly fetching bulk data and constructing their own locally stored histories.

Regarding the state of the draft, as I understand it the working group has a full plate at present, so while we would like to proceed with this draft, we may need to simply keep it warm until it can be taken on as a working item - assuming, of course, the group is interested in this work!

— 
bje