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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 03 Sep 2015 04:15:19 -0700

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. 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.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 3 Sep 2015 05:23:38 -0700

Hi Stephen,

> On Sep 3, 2015, at 4:15 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 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
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Sep 2015 13:28:47 +0100

Hiya,

On 03/09/15 13:23, Alissa Cooper wrote:
>> 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/
>> 
>> 
>> 
>> 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.
> 
> 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).
> 
> 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.

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
t3: This WG defines how to annotate a location with an identity
    thus creating location objects

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).
>> 
>> 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, 
>> My propsed NEW text is very clunky so probably needs improving.
>> 
>> 
>> 
>> 
>> _______________________________________________ Geopriv mailing
>> list [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 3 Sep 2015 06:14:02 -0700

> On Sep 3, 2015, at 5:28 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

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).

>    The foo-wg doesn't consider security/privacy as geojson doesn't

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).

>    thus creating location objects

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

Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Sep 2015 14:19:31 +0100

scroll on down...

On 03/09/15 14:14, Alissa Cooper wrote:
>>>> 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.)
>>>> 
>>>> 
>>>> 
>>>> 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.
>>> 
>>> 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).
>>> 
>>> 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,
> 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).
> 
>> 
>> 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.

> 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.

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).
>>>> 
>>>> extensibility would be harmful.
>>>> 
>>>> NEW:
>>>> 
>>>> geojson object an RFC6280 location object or location
>>>> information as defined by RFC3693.  Should such an extension be
>>>> needed, re-chartering will be required.
>>>> 
>>>> _______________________________________________ Geopriv
>>>> mailing list [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 3 Sep 2015 07:57:42 -0700

Suggestion below.

> On Sep 3, 2015, at 6:19 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> scroll on down...
> 

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Sep 2015 15:58:47 +0100

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.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 3 Sep 2015 08:02:53 -0700

Ok, one more try and we’re there I think:

OLD

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 <[email-masked]> wrote:
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Sep 2015 16:03:19 +0100

Lovely.

Thanks,
S.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Sep 2015 11:49:25 -0400

I have been following this discussion, but haven't been able to make 
sense of it. :-(

IIUC, the question is how to restrict GeoJSON so that it can't be used 
to represent Location Objects (loosely as defined in RF6280) because it 
doesn't have a way to include Privacy Rules. ISTM that this is an 
*impossible* goal.

If you pass a representation of a geographic location where a target 
might be, then it may be possible for that location to be associated 
with a target contextually. This may be true without the knowledge of 
the sending application. (And possibly even without the knowledge of the 
receiving application.) The relationship may be inferred via complex 
data mining.

For that matter, even the statement of the goal is problematic. In 6280 
LO is defined as "location information together with Privacy Rules". I 
guess GeoJSON doesn't aspire to represent privacy rules, but I don't see 
how doing so would be a problem.

Perhaps the goal should be to forbid a GeoJSON object from *containing* 
a representation of a *target* (as defined in 6280). This would not 
prevent a target from being associated with it contextually, but at 
least the users will not need to consider what might be *within* the 
GeoJSON object when analyzing whether there are privacy concerns.

	Thanks,
	Paul

On 9/3/15 10:57 AM, Alissa Cooper wrote:
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 3 Sep 2015 09:51:54 -0600

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: [email-masked] ; [email-masked] ; Erik Wilde ; IESG
Subject: Re: [Geopriv] Stephen Farrell's Block on 
charter-ietf-geojson-00-01: (with BLOCK)

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.

---

From: Robin Wilton <[email-masked]>
Date: Thu, 3 Sep 2015 16:14:53 +0000

Sorry, only just seen this thread - but I have read back through the dialogue.

I don’t want to propose a change to the final suggested text, but I would like to check an assumption (of mine) about privacy risk.

In one of his replies, Stephen gave a timeline to illustrate how something might be developed in compliance with the GeoJSON spec and *not*, in itself, give rise to privacy concerns, but might subsequently be extended/modified in such a way *did* give rise to privacy concerns.

The assumption I wanted to check was this: I assume (having been through a similar cycle in another standards development context) that this is another instance of a recurring problem - namely, that if you design specs to be “composable”, you have to deal with the possibility that one apparently innocuous element could be combined with another element in ways that make it more harmful. The question then is, what level of (in this case privacy-related) warning/disclaimer should you put on the element that, on its own, is harmless.

As I say, I don’t want to change the text proposed, just to check if the problem, here, is of the species I’ve described above.

Yrs.,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 7 Sep 2015 06:34:05 -0700

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 <[email-masked]> 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.
> 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 :-)
> 
> -----Original Message----- From: Alissa Cooper
> Subject: Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 9 Sep 2015 17:53:11 -0700

Hi Paul,

I don’t think the goal is to prevent anything necessarily. I think the point is to express in the charter what the group plans to do, what requirements flow from that, and the circumstances under which a re-charter would be necessary. I agree with you that what we can limit here is what the WG will work on, not what people will do with that output.

The point of discussing the relationship between a GeoJSON object and a LO was to point out that a GeoJSON object itself does not specify the location of a target, but rather just a location. Perhaps that point could be made more clearly without talking about location objects at all, if that is confusing?

Alissa

> On Sep 3, 2015, at 8:49 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> I have been following this discussion, but haven't been able to make sense of it. :-(
> 
> IIUC, the question is how to restrict GeoJSON so that it can't be used to represent Location Objects (loosely as defined in RF6280) because it doesn't have a way to include Privacy Rules. ISTM that this is an *impossible* goal.
> 
> If you pass a representation of a geographic location where a target might be, then it may be possible for that location to be associated with a target contextually. This may be true without the knowledge of the sending application. (And possibly even without the knowledge of the receiving application.) The relationship may be inferred via complex data mining.
> 
> For that matter, even the statement of the goal is problematic. In 6280 LO is defined as "location information together with Privacy Rules". I guess GeoJSON doesn't aspire to represent privacy rules, but I don't see how doing so would be a problem.
> 
> Perhaps the goal should be to forbid a GeoJSON object from *containing* a representation of a *target* (as defined in 6280). This would not prevent a target from being associated with it contextually, but at least the users will not need to consider what might be *within* the GeoJSON object when analyzing whether there are privacy concerns.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Sep 2015 11:09:40 -0400

Alissa,

> I don’t think the goal is to prevent anything necessarily. I think the point is to express in the charter what the group plans to do, what requirements flow from that, and the circumstances under w…

OK

> The point of discussing the relationship between a GeoJSON object and a LO was to point out that a GeoJSON object itself does not specify the location of a target, but rather just a location. Perha…

Yes. I found the ref to LO to add confusion about what the point was.
I think just saying that a GeoJSON object is not intended to contain 
identification of a target would do the trick.

	Thanks,
	Paul

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 11 Sep 2015 11:11:23 -0600

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 ; [email-masked] ; 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

> 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).
>
> 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:
>
> 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 
> :-)
>