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

[Alissa Cooper <[e-mail]>]

Suggestion below.

> On Sep 3, 2015, at 6:19 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> scroll on down...
> 
> On 03/09/15 14:14, Alissa Cooper wrote:
>> 
>>> 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).
> 
> 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.
> 
>> 
>>> 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.
> 
> 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.

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

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