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

Alissa Cooper <> Thu, 03 September 2015 13:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C44531B3DB2 for <>; Thu, 3 Sep 2015 06:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hcMBRR5jE9VS for <>; Thu, 3 Sep 2015 06:14:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7F071ACD7E for <>; Thu, 3 Sep 2015 06:14:05 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 5F1BE2042A for <>; Thu, 3 Sep 2015 09:14:04 -0400 (EDT)
Received: from frontend1 ([]) by compute3.internal (MEProxy); Thu, 03 Sep 2015 09:14:04 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; 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=flGfQVtNxdAzeH4ezdBTEH3oEhc=; b=Whjz1G eeWBVm6kwM1IjOMGXsSOLZ3iULD81yKED8G1+YTps+BnlgM0QUwbSM0PFPWXjA6l AppfWUFwk/Imc4TIFrDKpDWkvAdSQ/ilCN7GQewM9lS474HZSrV49peOVEdsgkzs MfpGs+xhAlQnW3XkspeHqxQmE/EbHs29RF6M8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; 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=flGfQVtNxdAzeH4 ezdBTEH3oEhc=; b=m86UITeufYrhDxQosJjYrYHaOYovJ8jewzgJwAXSU1lGiM0 axBAJQO9n31AkOVUY2j0yyd9yZGh62XswkcZg6obzBKBRip5ouKt74WZ1LBa4amt 1WQ1hFtGsOKRSjHDZNBzTntTSGBotUNMcX9jP8NowFIwD6ww2zUrS3mHU92Y=
X-Sasl-enc: EScDKc8l+Djj2vyce5xNRlJS6J25v1+67jFKG6FvavUu 1441286043
Received: from (unknown []) by (Postfix) with ESMTPA id 75B77C00287; Thu, 3 Sep 2015 09:14:03 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Thu, 3 Sep 2015 06:14:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc:,, Erik Wilde <>, IESG <>
Subject: Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Geographic Location/Privacy <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Sep 2015 13:14:09 -0000

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


> 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