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

["Carl Reed" <[e-mail]>]

Alissa -

Yes, thanks. Much appreciate the detailed response.

Regards

Carl


-----Original Message----- 
From: Alissa Cooper
Sent: Monday, September 07, 2015 7:34 AM
To: Carl Reed
Cc: Stephen Farrell ; geopriv mailing list ; [e-mail] ; Erik Wilde 
; IESG ; Scott Simmons ; Sean Gillies
Subject: Re: [Geopriv] Stephen Farrell's Block on 
charter-ietf-geojson-00-01: (with BLOCK)

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 <[e-mail]> 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: [e-mail] ; [e-mail] ; 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 <[e-mail]> 
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv