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

Byron Ellacott <bje@apnic.net> Tue, 28 November 2017 23:31 UTC

Return-Path: <bje@apnic.net>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42CA126D73 for <regext@ietfa.amsl.com>; Tue, 28 Nov 2017 15:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ckJm4Y9s_u3 for <regext@ietfa.amsl.com>; Tue, 28 Nov 2017 15:31:39 -0800 (PST)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0057.outbound.protection.outlook.com [104.47.126.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48F41205F0 for <regext@ietf.org>; Tue, 28 Nov 2017 15:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9mHjV0rotMPfy7BZ08SMODz+PY/ASrTBjatLJoyzbzg=; b=ZbGx8fyoq56ZPIHpOdw1oP6OIkR4Y2ElBdf8CwEzJDhUVWO92jJk+IGxceVrvvynr/7rNg8n7r02vgG3Su+A/j3a+TAe+4I2ov7vW9Yat1x/KSkMcvAlJSKztxwN9i8Df/JVhr95HMF/gIoNIVzA8fifo8W3WgAH5nOxKREeoD4=
Received: from HK2PR0401MB2115.apcprd04.prod.outlook.com (10.170.147.23) by HK2PR0401MB2113.apcprd04.prod.outlook.com (10.170.147.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 23:31:35 +0000
Received: from HK2PR0401MB2115.apcprd04.prod.outlook.com ([fe80::8937:7edb:bd50:9bd4]) by HK2PR0401MB2115.apcprd04.prod.outlook.com ([fe80::8937:7edb:bd50:9bd4%18]) with mapi id 15.20.0260.007; Tue, 28 Nov 2017 23:31:35 +0000
From: Byron Ellacott <bje@apnic.net>
To: Patrick Mevzek <pm@dotandco.com>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] News of draft-ellacott-historical-rdap?
Thread-Index: AQHTaDisQB8mRJ5s9UuJez0FlLPm66Mpz1gAgACiQgA=
Date: Tue, 28 Nov 2017 23:31:35 +0000
Message-ID: <E20C8A89-449D-41BD-B1A1-96029EFD02C8@apnic.net>
References: <20171128110417.35ez2rvbpdvgnpi4@nic.fr> <1511877048.1444775.1186783536.5BAA0ACD@webmail.messagingengine.com>
In-Reply-To: <1511877048.1444775.1186783536.5BAA0ACD@webmail.messagingengine.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bje@apnic.net;
x-originating-ip: [2001:dc0:2001:210:f9d3:a0e5:f89b:898d]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2PR0401MB2113; 6:CauskWbq2iAX2yLcEP9g70Z07LyIQiDY+4GVEQt1/WyiMz0GU+ThLm37inPc5u7eGeigEFyr0wkb9EJVLkt4CzeNKc4gJiXG36LkHV0XGkSyYW5uKtgxihhOrWF7I7Lh5GT7ogSDw7mpj0u3CAkfkIllfdqDwT8vs+ndWQqHgOMlJfdx5dLq/ATV1iLEuKSFOmyE6VgY7ZMY/T04KOwNWau5iogM7gBmPt4dI6JV72VmIq8/2NalaoFMllnsBkjXoSe3sbtJeCWuZo1UDipVEnuPaHUzAxa1WmchOg7DQMiavcYZzG0uoWP4ChdR6QfoNDpWhv6xv2E/q8xWHcCFne0rQiOtxNbJLsxjq+EMrqQ=; 5:6NaYhTUIMVHEUEmJSED+b89OTnWsfjoZEKtXFTf2W6eMplItwKI4LUDMO7ahdJf2wZ0cOFWR+YM5dVefotMtZWGlco2sQFjhAdaR3OfhQYcs/N+1yXo0pG1kI9Ccfn+PnVrSHABDCveAyZe0CnlyW8kOK8bpis5G6QkRWUhMvKU=; 24:MG/9/nntelyjZ87zFiVZUJfMiG0DPDXx4gwAOg8ISjIBrssvcnBaeBsD3v+mUFffqmMrHtJyU2WKHm3z7dvhAn7gtmUIUJrHO7cDPMee7vw=; 7:uk2WEafV+S6iKSYduivqUm7BCiQh6NT4/qYDxitqWhygpw6kqByEXxOG7Pxk854eQ6T3byK/6vTy5UomyVurlrfOJ3LGjt6NA02ycJHPWgYA1AOkKUQFUbgrCnRWmEVI6OP8kYk+bpZXLTzY6dY1sYVREc/L7JitefSIMt3acr2D+j/ZDswVu2+0LSP1Y6YvZSSU7PPV6DMNdwECe2tvRCzK6H0wIwKd7xaF+GDlZH2gP65nLsAcyJGYXGqmrTAa
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b252859a-0dcf-4cca-ee86-08d536b82a68
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603261); SRVR:HK2PR0401MB2113;
x-ms-traffictypediagnostic: HK2PR0401MB2113:
x-microsoft-antispam-prvs: <HK2PR0401MB211369283EEEE2ADD4345703B33A0@HK2PR0401MB2113.apcprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(120809045254105)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(201703131423075)(201703061421075)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:HK2PR0401MB2113; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HK2PR0401MB2113;
x-forefront-prvs: 0505147DDB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(366004)(199003)(189002)(24454002)(3280700002)(68736007)(82746002)(508600001)(81166006)(102836003)(6116002)(83716003)(81156014)(6436002)(6506006)(6486002)(6246003)(3660700001)(99286004)(6306002)(14454004)(36756003)(2950100002)(8936002)(8676002)(53936002)(6916009)(86362001)(53546010)(6512007)(189998001)(5250100002)(230783001)(76176999)(54356999)(7736002)(97736004)(101416001)(2906002)(105586002)(50986999)(4326008)(25786009)(305945005)(229853002)(2900100001)(5660300001)(106356001)(33656002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:HK2PR0401MB2113; H:HK2PR0401MB2115.apcprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: apnic.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <69B78A4413DA0442934CA80606647730@apcprd04.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b252859a-0dcf-4cca-ee86-08d536b82a68
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 23:31:35.5101 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR0401MB2113
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/u4GEq4d5w6QCKe9KirxOy6FHJU8>
Subject: Re: [regext] News of draft-ellacott-historical-rdap?
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Nov 2017 23:31:41 -0000

Hi,

> On 28 Nov 2017, at 11:50 pm, Patrick Mevzek <pm@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