Re: [Enum] Expert Review draft-goix-appsawg-enum-acct-uri: Approved

Lawrence Conroy <lconroy@insensate.co.uk> Mon, 13 January 2014 17:05 UTC

Return-Path: <lconroy@insensate.co.uk>
X-Original-To: enum@ietfa.amsl.com
Delivered-To: enum@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946091AE0E0 for <enum@ietfa.amsl.com>; Mon, 13 Jan 2014 09:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 CVf0d9kFRvdC for <enum@ietfa.amsl.com>; Mon, 13 Jan 2014 09:05:32 -0800 (PST)
Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0203F1ADFA3 for <enum@ietf.org>; Mon, 13 Jan 2014 09:05:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 4CF4D12005E1; Mon, 13 Jan 2014 17:05:20 +0000 (GMT)
Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJm0Pu+zssWP; Mon, 13 Jan 2014 17:05:19 +0000 (GMT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id 8B63D12005D6; Mon, 13 Jan 2014 17:05:19 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Lawrence Conroy <lconroy@insensate.co.uk>
In-Reply-To: <20140113150859.GB23573@x28.adm.denic.de>
Date: Mon, 13 Jan 2014 17:05:18 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <748A8106-F79C-4DD7-AB53-DCB29388E16C@insensate.co.uk>
References: <alpine.DEB.2.00.1401131529100.19715@softronics.hoeneisen.ch> <20140113150859.GB23573@x28.adm.denic.de>
To: Peter Koch <pk@DENIC.DE>
X-Mailer: Apple Mail (2.1085)
Cc: IETF ENUM list <enum@ietf.org>, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
Subject: Re: [Enum] Expert Review draft-goix-appsawg-enum-acct-uri: Approved
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/enum/>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2014 17:05:34 -0000

Hi Peter, Bernie, folks,
OK --- I guess your concern is 2119 style commands to humans?
Re. user role -- well, a user who wants to tell people his/her account may well NOT be a zone maintainer, but his/her choice may well control the behaviour of the zone maintainer.

Given the level of self-publication of PII on web services [like twitter or facebook] that the general populace seems to be happy to do, it's fairly obvious that we can tell them, but they may well not listen.
However, we can at least give the 2119-like uses as strong advice to any publisher (but, as in all things, IANAL and nor is anyone else here).
How else could we stress that these concerns really, definitely, should be on the user's list of things to think about?

If (say) a carrier or SNEW provider wants to use this scheme to publish acct data for users, then it really has to consider what data is published in DNS (and so is available to all).
If not, and it has the joy of being in EU jurisdictions, it might (just might) be sued under national embodiments of the EU Data Protection Directive.
So ... the user choice ("yes please tell the world my account name") may well require the potential publisher to say "did you REALLY mean that?" to get legal cover.

I can also imagine a carrier being more comfortable limiting publication using a split-horizon DNS model (as in the two examples in the doc).
One set of data for my systems because I'm liable for those anyway, with another for brother carriers to query; a private and semi-private ENUM scheme.

Re. public ENUM: concern on limiting publication of PII is not specific to this doc -- it's general to any RRSET.
We DID discuss advice on limiting PII publication in ENUM (and so in public ENUM); honest.
I have to admit, it didn't make it into 5483 or 6116, as (at the time) Security Considerations didn't really extend to privacy. Sigh.
It is, however, a requirement in 6117 -- if it wasn't mentioned in the acct Enumservice document, Bernie would have had to ask for it to be added.

all the best,
  Lawrence


On 13 Jan 2014, at 15:08, Peter Koch wrote:
> Bernie,
> 
>> Please be informed that after all issues could be resolved with the 
>> authors, the document draft-goix-appsawg-enum-acct-uri-06 has been expert 
>> approved.
> 
> it's been a while that i read and commented on a very early version, so here's
> a question. How would this paragraph in section 7 be interpreted:
> 
>   Users MUST therefore carefully consider the information provided in
>   the resource identified by the ENUM record as well as in the record
>   itself.  Considerations SHOULD include serving information only to
>   entities of the user's choice and/or limiting the comprehension of
>   the information provided based on the identity of the requestor.
> 
> Normative language is a bit tricky when it comes to directing human,
> especially end user, behaviour. In this particular case, it seems to suggest
> the user acts as a publisher (or, say, zone maintainer) and also seems to encourage
> selective publication even in the public ENUM tree?
> 
> -Peter
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www.ietf.org/mailman/listinfo/enum