Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)

Alissa Cooper <alissa@cooperw.in> Thu, 03 September 2015 13:14 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: geopriv@ietfa.amsl.com
Delivered-To: geopriv@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44531B3DB2 for <geopriv@ietfa.amsl.com>; Thu, 3 Sep 2015 06:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 hcMBRR5jE9VS for <geopriv@ietfa.amsl.com>; Thu, 3 Sep 2015 06:14:07 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F071ACD7E for <geopriv@ietf.org>; Thu, 3 Sep 2015 06:14:05 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5F1BE2042A for <geopriv@ietf.org>; Thu, 3 Sep 2015 09:14:04 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 03 Sep 2015 09:14:04 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=flGfQVtNxdAzeH4ezdBTEH3oEhc=; b=Whjz1G eeWBVm6kwM1IjOMGXsSOLZ3iULD81yKED8G1+YTps+BnlgM0QUwbSM0PFPWXjA6l AppfWUFwk/Imc4TIFrDKpDWkvAdSQ/ilCN7GQewM9lS474HZSrV49peOVEdsgkzs MfpGs+xhAlQnW3XkspeHqxQmE/EbHs29RF6M8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=flGfQVtNxdAzeH4 ezdBTEH3oEhc=; b=m86UITeufYrhDxQosJjYrYHaOYovJ8jewzgJwAXSU1lGiM0 axBAJQO9n31AkOVUY2j0yyd9yZGh62XswkcZg6obzBKBRip5ouKt74WZ1LBa4amt 1WQ1hFtGsOKRSjHDZNBzTntTSGBotUNMcX9jP8NowFIwD6ww2zUrS3mHU92Y=
X-Sasl-enc: EScDKc8l+Djj2vyce5xNRlJS6J25v1+67jFKG6FvavUu 1441286043
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 75B77C00287; Thu, 3 Sep 2015 09:14:03 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <55E83CFF.1040508@cs.tcd.ie>
Date: Thu, 3 Sep 2015 06:14:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in>
References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <CAFC1CD0-43EE-4F40-A755-C51D610FBD9A@cooperw.in> <55E83CFF.1040508@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/geopriv/KBqKRKwnyUoeHwQ2S8uL6leiEtY>
Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde <dret@berkeley.edu>, IESG <iesg@ietf.org>
Subject: Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geopriv/>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2015 13:14:09 -0000

> On Sep 3, 2015, at 5:28 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>; wrote:
> 
> 
> Hiya,
> 
> On 03/09/15 13:23, Alissa Cooper wrote:
>> Hi Stephen,
>> 
>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell
>>> <stephen.farrell@cs.tcd.ie>; wrote:
>>> 
>>> Stephen Farrell has entered the following ballot position for 
>>> charter-ietf-geojson-00-01: Block
>>> 
>>> When responding, please keep the subject line intact and reply to
>>> all email addresses included in the To and CC lines. (Feel free to
>>> cut this introductory paragraph, however.)
>>> 
>>> 
>>> 
>>> The document, along with other ballot positions, can be found
>>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> 
> BLOCK:
>>> ----------------------------------------------------------------------
>>> 
>>> 
>>> 
>>> 
> This seems like a fine thing to do, but I have one
>>> concern I'd like to chat about before we go ahead.
>>> 
>>> I could buy the "no privacy issues here" argument except for the
>>> last sentence which says: "As the WG considers extensibility it
>>> will be careful not to preclude extensions that would allow GeoJSON
>>> objects to become location objects unless the group determines
>>> such extensibility would be harmful." Aside from being hard to 
>>> parse, that seems to mean that some extensions could mean this
>>> format does become a RFC6280 Location object, which would then
>>> bring in the privacy and security issues, previously argued to be
>>> out of scope.
>> 
>> Maybe this is a verb tense problem, but I think the points of the
>> entire paragraph in question are:
>> 
>> 1) the format the group intends to create is for representation of
>> things that are not location objects 2) even so, depending on how the
>> format is specified, it may be possible for them to get used in ways
>> in which they become location objects, in which case the privacy and
>> security considerations kick in 3) in defining how to make the format
>> extensible, the group does not want to preclude (2) in the future,
>> but 4) the group will not be defining specific extensions to achieve
>> (2).
>> 
>> Here is a re-phrase that tries to capture this better:
>> 
>> The WG will be careful to craft its extensibility mechanism such that
>> extensions that would allow GeoJSON objects to become location
>> objects are not precluded, but will not be defining such extensions
>> itself. Should such an extension be needed, re-chartering will be
>> required.
>> 
>> Is that better?
> 
> Yes. Definitely clearer.
> 
> However, the "not precluded" is a bit troubling still.

I think the thing is that you don’t want to specify this format such that it could never describe the location of a person or a device, because that would be an a priori limiting constraint on its utility. So the point is to leave the door open via the extensibility mechanism, but not design specific extensions to do this (unless there’s a re-charter).

> 
> Let me try get to it this way - in the following timeline who/when
> would address the security/privacy issues and how'd we be confident
> that'd really happen?
> 
> t1: This WG does it's planned stuff.
> t2: The foo-protocol uses geojson in a PDU (and the bar protocol etc.)
>    The foo-wg doesn't consider security/privacy as geojson doesn't
>    create location objects

I think consideration for privacy/security could happen at t2 depending on how the foo-protocol uses the geojson object. So in this case we would rely on the remit of the foo-wg (this is the "When a GeoJSON object is used in a context where it identifies the location of a Target …” sentence).

> t3: This WG defines how to annotate a location with an identity
>    thus creating location objects

Then certainly at t3 the geojson WG would address privacy/security. And this would be after re-charter.

Alissa

> 
> Ta,
> S.
> 
> 
> 
>> 
>> Alissa
>> 
>>> I think that's a contradiction. As it happens, I also think that,
>>> despite folks best efforts, RFC6280 isn't an architecture that 
>>> worked out that well, so I'd not suggest that this wG try emulate
>>> that with square brackets. Instead, I'd suggest that this WG be
>>> chartered to never take on work with does have security or privacy
>>> consequences (without a re-charter).
>>> 
>>> That'd maybe mean a change in the last sentence such as:
>>> 
>>> OLD:
>>> 
>>> As the WG considers extensibility it will be careful not to
>>> preclude extensions that would allow GeoJSON objects to become
>>> location objects unless the group determines such extensibility
>>> would be harmful.
>>> 
>>> NEW:
>>> 
>>> In order to continue to validly avoid having to deal with the
>>> security and privacy issues that would arise, this WG will not
>>> define any extensions that would have the effect of making a
>>> geojson object an RFC6280 location object or location information
>>> as defined by RFC3693.  Should such an extension be needed, 
>>> re-chartering will be required.
>>> 
>>> My propsed NEW text is very clunky so probably needs improving.
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________ Geopriv mailing
>>> list Geopriv@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>