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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 03 September 2015 12:31 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: geopriv@ietfa.amsl.com
Delivered-To: geopriv@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508331AD0C3; Thu, 3 Sep 2015 05:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cdh2gfvxcX3; Thu, 3 Sep 2015 05:31:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9B01B3CCF; Thu, 3 Sep 2015 05:28:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 332B3BE49; Thu, 3 Sep 2015 13:28:54 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlnK7iNkObfK; Thu, 3 Sep 2015 13:28:47 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9DF3BBE54; Thu, 3 Sep 2015 13:28:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441283327; bh=vjlWcFb378yG1Muloz9F96zzbOgLS8ez3eoB6oFmuLs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=hy49P9MI4jDbxJbopeRJ968v7uJNJXskXDtmnpiiro6Ta89pNLrqezm9PaLA/fTff Z1jIOsvucb/Sw6vePpT8mZsaKmC6GlUgblrK1nuutFW4r3XtJZ8Jx1hr/lCoShhRNo MFLu0YAMI7xcN++PWSYTYKOS2B2T+5uEnJTzhFgQ=
To: Alissa Cooper <alissa@cooperw.in>
References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <CAFC1CD0-43EE-4F40-A755-C51D610FBD9A@cooperw.in>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <55E83CFF.1040508@cs.tcd.ie>
Date: Thu, 03 Sep 2015 13:28:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAFC1CD0-43EE-4F40-A755-C51D610FBD9A@cooperw.in>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/geopriv/_TBzdDQ6KCxy7KqMMArS3C0VAqY>
Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde <dret@berkeley.edu>, IESG <iesg@ietf.org>
Subject: Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geopriv/>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2015 12:31:45 -0000

Hiya,

On 03/09/15 13:23, Alissa Cooper wrote:
> Hi Stephen,
> 
>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> 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.

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).
>> 
>> 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 Geopriv@ietf.org 
>> https://www.ietf.org/mailman/listinfo/geopriv
>