Re: [Geopriv] LCP & Arch....

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Thu, 17 September 2009 07:56 UTC

Return-Path: <hannes.tschofenig@nsn.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B90A3A688F for <geopriv@core3.amsl.com>; Thu, 17 Sep 2009 00:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.302
X-Spam-Level:
X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuFiaLtWww+q for <geopriv@core3.amsl.com>; Thu, 17 Sep 2009 00:56:25 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 6DE0E3A67DD for <geopriv@ietf.org>; Thu, 17 Sep 2009 00:56:25 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n8H7vArC020986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2009 09:57:10 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n8H7vAbT026220; Thu, 17 Sep 2009 09:57:10 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 09:57:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA376C.74A294B4"
Date: Thu, 17 Sep 2009 10:57:08 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501B2DC74@FIESEXC015.nsn-intra.net>
In-Reply-To: <C6D6C84B.1B59A%mlinsner@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] LCP & Arch....
Thread-Index: Aco3D5lUW+p3tOnWUUeITBGFPhYCYwAUMuIg
References: <C6D6C84B.1B59A%mlinsner@cisco.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Marc Linsner <mlinsner@cisco.com>, GEOPRIV <geopriv@ietf.org>
X-OriginalArrivalTime: 17 Sep 2009 07:57:10.0450 (UTC) FILETIME=[75B87920:01CA376C]
Subject: Re: [Geopriv] LCP & Arch....
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 17 Sep 2009 07:56:31 -0000

I guess we are only discussing terminology here (and most people outside
the GEOPRIV working group very likely have no interest in any of these
discussions nor the outcome). 
 
So, some time ago we defined the term LCP in a quite loose way when we
worked on the L7 LCP topic. 
The goal was to have some "label" for referring to protocols
(DHCP,HELD,LLDP-MED,..) that provide the Device with its own location
information. 
 
Marc, what should we do to have a single term for these protocols that
is still meaningful and does not cause heartburn in the DHCP vs. HELD
camp? 
 
Ciao
Hannes
 
PS: I noticed that it might be useful to re-read the draft
http://www.ietf.org/id/draft-ietf-geopriv-l7-lcp-ps-10.txt regarding the
terms 'Device' vs. 'Target'... 


________________________________

	From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
On Behalf Of ext Marc Linsner
	Sent: 16 September, 2009 23:52
	To: GEOPRIV
	Subject: [Geopriv] LCP & Arch....
	
	
	To add more to my rant about LCP on the interim meeting call
yesterday.....
	
	LCP is an aberration of the GeoPriv architecture.  Early on, the
GeoPriv work group agreed to allow LCP based on the fact the underlying
communication protocol would ensure the LCI provided belonged to the
recipient.  Hence, no work required at the LS/LIS to verify that the
requester is the target.  It was never agreed that LCP was a 'function'
that GeoPriv would provide, but LCP is simply an aberration that shares
the baggage associated with the GeoPriv Privacy architecture with a
communication protocol that can provide the guarantees as described.
	
	Hence, we have created 2 LCP solutions, DHCP and (baseline)
HELD.   Both these mechanisms protect the privacy of the location data
as they guarantee that the target is the recipient.  Any mechanism where
the communication protocol cannot provide this guarantee MUST be
considered 'not an LCP' and follow the whole GeoPriv privacy/security
architecture (policy set by rulemaker, enforced by LS/LIS, etc.).  
	
	My hope is to dispel the myth that LCP is a 'right' that target
has to gain access to it's own location data and GeoPriv must deliver on
this 'right' at all costs.  The overall privacy/security architecture
must still be followed when a target is discovering it's own location
(trust relationships, identity verification, rule-based policy, etc.).
	
	-Marc-