Re: [netmod] GDPR and private data

Robert Varga <nite@hq.sk> Mon, 31 May 2021 19:38 UTC

Return-Path: <nite@hq.sk>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFBD3A23F9 for <netmod@ietfa.amsl.com>; Mon, 31 May 2021 12:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 QEDbJd26TZXK for <netmod@ietfa.amsl.com>; Mon, 31 May 2021 12:38:37 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957B43A23F7 for <netmod@ietf.org>; Mon, 31 May 2021 12:38:37 -0700 (PDT)
Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 23253240158; Mon, 31 May 2021 21:38:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1622489910; bh=ANtyfSVUMoD4sVM8XokkGHgDxsgTaFEejwx7OCQ74Yo=; h=To:References:From:Subject:Date:In-Reply-To; b=Y7qBfkEBg4Dxn2VLtthrP33wLxBGhVRBp4IivmmLRRq5whwar6XKOOnjMKusizBn+ 5CZ1DhFXdX80QuG4BakKnpo9GQmafYySWwZnlgATFmMeBACKfGSML28DnDgiM0IG0h sSeyIj34y9azQ8DSx/Y37MlqaxN4kyoCKL3A8ZBg=
To: Balázs Lengyel <balazs.lengyel=40ericsson.com@dmarc.ietf.org>, "'netmod@ietf.org'" <netmod@ietf.org>
References: <AM8PR07MB8230C7C05FA2FDB5475234A2F0249@AM8PR07MB8230.eurprd07.prod.outlook.com>
From: Robert Varga <nite@hq.sk>
Message-ID: <282ad4b7-5019-56ca-c3d6-ee624bce5ae0@hq.sk>
Date: Mon, 31 May 2021 21:38:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <AM8PR07MB8230C7C05FA2FDB5475234A2F0249@AM8PR07MB8230.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="RT5EBVQJwpmp6cxX0j5X8WsAzCzg1FZdl"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-agwboMWb7cpvL9-YQl_9NusvGc>
Subject: Re: [netmod] GDPR and private data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 May 2021 19:38:44 -0000

On 26/05/2021 11:49, Balázs Lengyel wrote:
> Hello,
> 
> Netconf/Restconf can transfer a lot of data. Some of this data can be
> personal/private like end-user names, personal phone records, street
> addresses. Is there a way to marks such data as private? I am thinking
> about something like putting a YANG extension in the data models:
> 
>  
> 
> extension private-data {
> 
>     description
> 
>       "Indicates that a leaf or leaf-list contains private data.
> 
>     argument privacy-type;
> 
>   }
> 
>  
> 
> Is there any standard solution for this or any proposal ? In the world
> of GDPR we should be thinking about this.
I do not believe a static extension like this is going to cut it. The
basic assumption it makes is that data provenance can be established at
design time -- and that runs contrary to the fact that data can be
derived from other data via processing.

I think an RFC7952-based annotation would be more appropriate: it would
work outside of the static model to positively identify that a
particular leaf value in fact contains privacy-sensitive data and the
receiving system should treat it as such.

Regards,
Robert