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

Alissa Cooper <alissa@cooperw.in> Thu, 03 September 2015 14:58 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 68E011B49D3 for <geopriv@ietfa.amsl.com>; Thu, 3 Sep 2015 07:58:15 -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 10hMbzerF5MG for <geopriv@ietfa.amsl.com>; Thu, 3 Sep 2015 07:58:13 -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 5AE231B4A3C for <geopriv@ietf.org>; Thu, 3 Sep 2015 07:57:45 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CB55B23DD4 for <geopriv@ietf.org>; Thu, 3 Sep 2015 10:57:44 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 03 Sep 2015 10:57:44 -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=bpgUz0jPb4JrCMv6oHEM9wwvGVE=; b=T8INSU jYa7R16SEcz0H85KdjUgOworSbYqOMFH4RM5Kidcn7Bgk4dQkuFdhULAhW91+mU6 famK3meurP+KQRMYQfSqRHB4RDvVwc5wY3I55Z05LmaM0TZnMZBY+a8dZMUV1c1E Tx+kZxjqDi9oLcxrxMS0oap+mBrSg3oG2CIOM=
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=bpgUz0jPb4JrCMv 6oHEM9wwvGVE=; b=pxy40wmOGtf40ZxJ1VF6uGb3239WkX+U5iWhRFlMHUSTIoz bw3yWnAXSXTsCdkL8YDyou1T43YnGLf+IyrpBZwxWB/+5+9XftlF/NpPUusr9bCM njfqZY66oGeCqyxaERbYa2oYXPgSOIa1YYLmEG7UvueExTn9bccYNqBVD7nw=
X-Sasl-enc: MLJ3ZXb7KtNES/lqfr1xYJOWPtl5Wwn10I7FizAEZeAP 1441292264
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id E413FC00286; Thu, 3 Sep 2015 10:57:43 -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: <55E848E3.10403@cs.tcd.ie>
Date: Thu, 3 Sep 2015 07:57:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in>
References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <CAFC1CD0-43EE-4F40-A755-C51D610FBD9A@cooperw.in> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@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/mMipZGpm6oSdHzERPczXZC7eUZs>
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 14:58:15 -0000

Suggestion below.

> On Sep 3, 2015, at 6:19 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>; wrote:
> 
> 
> scroll on down...
> 
> On 03/09/15 14:14, Alissa Cooper wrote:
>> 
>>> 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).
> 
> But at t2, the foo-wg doesn't know that a geojson object can e.g.
> include my photo or FB name or whatever so they can't take that
> into account.
> 
>> 
>>> 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.
> 
> Even if that re-charter says to consider the foo-protocol and
> the bar-protocol, it'd likely be too late to handle things well.
> 
> On balance I think I'd argue that this charter would be better to
> just say "no security/privacy stuff needed" (as it currentlyu does)
> but to not get into extensibility and how that might affect privacy
> at all.

How about this?

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
Should extensions that would allow GeoJSON objects to become location objects be needed, re-chartering will be required.

Alissa

> 
> Cheers,
> S.
> 
> 
>> 
>> 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
>>>> 
>>