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

Alissa Cooper <alissa@cooperw.in> Mon, 07 September 2015 13:34 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 6DA021A8748 for <geopriv@ietfa.amsl.com>; Mon, 7 Sep 2015 06:34:10 -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 bPhjUquGkgR0 for <geopriv@ietfa.amsl.com>; Mon, 7 Sep 2015 06:34:08 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113781A87AF for <geopriv@ietf.org>; Mon, 7 Sep 2015 06:34:08 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7312A21105 for <geopriv@ietf.org>; Mon, 7 Sep 2015 09:34:07 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 07 Sep 2015 09:34:07 -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=KeDpLlFq7j9Q/Lt7mp91h8TBFLA=; b=woZISK JkK2y0tDAlvR48QQoVTtjtWACY43tWlZuaJtSJ6z29HrTBfO2/lttWg4skcuClOs iX0s/3l+Uz7psEHKQ1dT+HxEZ0kMoFA8j9hfdZWItdDPD4NZT58/byxm67GaRO+7 NWt+tLiii9aNTpRC3oaUYq2+XiAP3BO7PZK9w=
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=KeDpLlFq7j9Q/Lt 7mp91h8TBFLA=; b=a9Xyc7wxgFpp/FrLSdfel6SdPhd88HcFagrdOyrMebju0Ev zoDjWJRT6Z81VxaHURZ2AmsqDh7VAnc4wxTk84mGSz2GGtATykbVMOaPTS5Xdx4B S+KP3bYLkJZHzjZ3KJQfYNVFyy4D2sGJ+dnDbgdmOFsSZRWICK7y7+e9rmRk=
X-Sasl-enc: nx3nDRK3KNbv5JuwiMcMTMKuThItHu9g4+wM3NrkFHTG 1441632847
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 4229CC00285; Mon, 7 Sep 2015 09:34:06 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: text/plain; charset=utf-8
From: Alissa Cooper <alissa@cooperw.in>
X-Priority: 3
In-Reply-To: <E4803BA91D0F4D2B8A5F2D24535C10DE@OfficeHP>
Date: Mon, 7 Sep 2015 06:34:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <236228C1-7506-4009-AA78-62EEF3C3FF8F@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> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86027.9050903@cs.tcd.ie> <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> <E4803BA91D0F4D2B8A5F2D24535C10DE@OfficeHP>
To: Carl Reed <creed@opengeospatial.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/geopriv/TORQ4CmTON5hpt4ECXMOX84o9d0>
Cc: geopriv mailing list <geopriv@ietf.org>, dispatch@ietf.org, Erik Wilde <dret@berkeley.edu>, Scott Simmons <ssimmons@opengeospatial.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, 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: Mon, 07 Sep 2015 13:34:10 -0000

Hi Carl,

Thanks for this. I think the paragraph in the charter about whether GeoJSON objects are LOs was focusing on the target identity aspect. That is, the definitions of LO given in RFC 3693 and RFC 6280 both assume that a location object describes the location of a target device. I definitely appreciate that there are other implications of saying something is or is not a LO, so perhaps the charter needs some re-phrasing.

The current thinking coming out of IETF 93 seemed to be that the GeoJSON spec will define GeoJSON objects such that they represent geographic features only and do not specify associations between geographic features and particular devices. Of course, it will be fairly trivial for developers to associate those objects with target identities of some sort — the whole point of specifying a json format is to make it easier to use geo information in applications. And if the format is built to be extensible, which generally would be a good thing, that raises the question about the point at which we need to deal with the associated privacy and security issues at the spec level should the format be extended to associate a location with a target. To put it another way, the base spec could be written (1) to preclude extensibility of this sort, (2) to allow extensibility of this sort with the expectation that when extensions are defined, the associated privacy and security implications will be addressed, or (3) to allow extensibility of this sort and explain how future extensions need to address privacy and security. Personally I think (1) is unlikely given the versatility of json. The text Stephen and I were debating was aimed at (2). You seem to be suggesting (3). Does that seem like an accurate assessment?

Alissa

> On Sep 3, 2015, at 8:51 AM, Carl Reed <creed@opengeospatial.org>; wrote:
> 
> Sorry to jump in. I have now read the entire thread, reviewed the charter, and reviewed a number of RFCs on this topic (starting with 4119). Been a while! Before starting, I wish to state that I am not opposed to this WG activity - GeoJSON is an important spec and one now being used in OGC standards work as informational. I just have some concerns.
> 
> In my mind, there is perhaps a more fundamental question: What is a Location Object? Back with the LO activity first started, the focus was on extending PIDF to include location content. From that perspective, privacy and location are closely coupled. However, over time the use of the location object became uncoupled from PIDF and as a result a number of other RFCs now speak to how to use a LO with SIP, RADIUS, and so on. Essentially, a LO can also be viewed as a stand alone package of location content with additional attributes such as uncertainty. When I worked on these RFC, I never viewed LO as being tightly coupled with privacy but always viewed the LO as a data package that could be used with any number of other standards/specs or even as a standard alone payload. This is exactly what has happened. Don't get me wrong - the privacy implications associated with location are critical - and scary. Predictive analytics experiments have shown that future individual movement activity can be predicted with close to 95% accuracy by analyzing past movement behavior (a joint Harvard/MIT study).
> 
> Therefore, I would suggest that a GeoJSON encoded payload is a location object. Consider that the PIDF-LO geodetic model is encoded using GML. The abstract model for geometry used in GML is ISO 19107: Spatial Schema (which is now in revision). The GeoJSON geometry model is also based on ISO 19107. The main difference between the two (other than the LO requirement for additional geometry types) is that GeoJSON encodes coordinates as longitude/latitude. GML encodes coordinates as latitude-longitude. There are also differences in how other coordinate reference systems are handled. While these differences are properly documented, I would strongly encourage the planned activity to consider:
> 
> 1. Documenting the relationship (similarities and differences) between GeoJSON and a LO. This would allow developers to choose the appropriate implementation approach.
> 2. Have a section on threat analysis and security
> 3. Speak to how privacy issues could be addressed (back to item 1 also).
> 
> Perhaps I am being overly sensitive but location and privacy (along with provenance and uncertainty) are coming to the fore as major standards issues. The OGC is working these standards related issues more and more. Much of this is being driven by requirements to use location content associated "citizens as scientists" activities, volunteered geographic information, IoT, Smart Cities, and on and on.
> 
> I know the GeoJSON authors do not wish to "overload" the GeoJSON spec. As such, I suspect many of my concerns could be easily addressed by referencing appropriate content from existing IETF RFCs. For example, the content of 7459 Uncertainty and Confidence is quite appropriate for a GeoJSON encoding. Also, 7459 was reviewed and commented on by OGC Members :-)
> 
> Sorry for the long posting.
> 
> Regards
> 
> Carl Reed
> Geospatial Standards geek
> 
> -----Original Message----- From: Alissa Cooper
> Sent: Thursday, September 03, 2015 9:02 AM
> To: Stephen Farrell
> Cc: geopriv@ietf.org ; dispatch@ietf.org ; Erik Wilde ; IESG
> Subject: Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)
> 
> Ok, one more try and we’re there I think:
> 
> 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
> Extensions that would allow GeoJSON objects to become location objects are not expected to be defined in the WG. Should that be needed, re-chartering will be required.
> 
>> On Sep 3, 2015, at 7:58 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>; wrote:
>> 
>> 
>> Better again. You could maybe add that's not expected to happen
>> during the lifetime of this wg but that'd be fine.
>> 
>> S
>> 
>> On 03/09/15 15:57, Alissa Cooper wrote:
>>> NEW Should extensions that would allow GeoJSON objects to become
>>> location objects be needed, re-chartering will be required.
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv