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

Alissa Cooper <alissa@cooperw.in> Thu, 03 September 2015 12:23 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 67C521A6F9A for <geopriv@ietfa.amsl.com>; Thu, 3 Sep 2015 05:23:43 -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=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 Rme7SrjaQpFD for <geopriv@ietfa.amsl.com>; Thu, 3 Sep 2015 05:23:41 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410221B30FB for <geopriv@ietf.org>; Thu, 3 Sep 2015 05:23:41 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B057220740 for <geopriv@ietf.org>; Thu, 3 Sep 2015 08:23:40 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 03 Sep 2015 08:23:40 -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=yQhP8sT1yI/VoDpoLqLhbzIKSiI=; b=CrEViw mUeqfqcwSNd59MyARfT1zeMC+x8uEYKslN0vFRXM3mVjlJBAEzs01NZcSs9upkiR AYWCMaked/DqGipSp1z7E+L/GCe+0O5rDKwcjvX2MZLo09uXpksfiXBfsiZqNCla LfJZdDoTE2nYBIQAhUK88z8vKmPmIS4z+dvMU=
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=yQhP8sT1yI/VoDp oLqLhbzIKSiI=; b=V6RSpTgSfGOJLBf9H++IbXSho5rC0kM1rgEDHrzaSq8RrXT KBWCHOGnPkdEiH9jcu0W4xgOybfNeVjTOKW6hZyChBdw0USMbTPF8xah2S7zk8zx R0fNPz4oRiVyUNlSZOeVnrn+7Nf6bs1a/aqFNGlusgspIbyXnOV2yEH6I8ao=
X-Sasl-enc: D7v90Xj1AQfmZC37Svi8Z1Vu9xeQ9602ae5Pz36RI0X7 1441283020
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id DBCE0C0028F; Thu, 3 Sep 2015 08:23:39 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <20150903111519.12341.48799.idtracker@ietfa.amsl.com>
Date: Thu, 3 Sep 2015 05:23:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CAFC1CD0-43EE-4F40-A755-C51D610FBD9A@cooperw.in>
References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/geopriv/jmxxIjc6g5c_TRdSoybiSO4UPvs>
Cc: geopriv@ietf.org, Erik Wilde <dret@berkeley.edu>, dispatch@ietf.org, 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 12:23:43 -0000

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?

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