Hi, > On 28 Nov 2017, at 11:50 pm, Patrick Mevzek <p...@dotandco.com> wrote: > > On Tue, Nov 28, 2017, at 12:04, Stephane Bortzmeyer wrote: >> 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? > > 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.
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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
