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

[Alissa Cooper <[e-mail]>]

> On Sep 3, 2015, at 5:28 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> On 03/09/15 13:23, Alissa Cooper wrote:
>> Hi Stephen,
>> 
>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell
>>> <[e-mail]> 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).

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

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