Re: [Geopriv] WG2LC: draft-ietf-geopriv-held-identity-extensions-00.txt

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Thu, 17 September 2009 16:39 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 321D93A6819 for <geopriv@core3.amsl.com>; Thu, 17 Sep 2009 09:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level:
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599]
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 CSdZtY-w93ph for <geopriv@core3.amsl.com>; Thu, 17 Sep 2009 09:39:20 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7F1EB3A69BB for <geopriv@ietf.org>; Thu, 17 Sep 2009 09:39:18 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n8HGe6AN023897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2009 18:40:06 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n8HGe6Cv022673; Thu, 17 Sep 2009 18:40:06 +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 18:40:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Sep 2009 19:43:00 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501B2E07B@FIESEXC015.nsn-intra.net>
In-Reply-To: <C6D7DDB1.1B66B%mlinsner@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] WG2LC: draft-ietf-geopriv-held-identity-extensions-00.txt
Thread-Index: Aco3tPD5Uy8cs3SIVEGcra+BzuMN/gAALoqw
References: <OF8A838401.3FCA578D-ON80257634.0057DC60-80257634.00585CC5@nominet.org.uk> <C6D7DDB1.1B66B%mlinsner@cisco.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Marc Linsner <mlinsner@cisco.com>, Ray.Bellis@nominet.org.uk
X-OriginalArrivalTime: 17 Sep 2009 16:40:06.0677 (UTC) FILETIME=[8368C450:01CA37B5]
Cc: GEOPRIV <geopriv@ietf.org>
Subject: Re: [Geopriv] WG2LC: draft-ietf-geopriv-held-identity-extensions-00.txt
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 16:39:21 -0000

Well. Think about all the work that is going on in the IETF when it
comes to transition architectures and considering not-updated devices. I
believe that there is now in the IETF more interest to meet the
expectations of the deployment rather than designing clean-slate
architectures. 
 
Example to support my statement: Proxy Mobile IP, IPv4/IPv6 transition
 
Ciao
Hannes
 
PS: I very strongly believe that we have to care about the intermediate
deployment stages as well since we otherwise will never get to the final
stage either. 

 

________________________________

	From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
On Behalf Of ext Marc Linsner
	Sent: 17 September, 2009 19:36
	To: Ray.Bellis@nominet.org.uk
	Cc: GEOPRIV
	Subject: Re: [Geopriv] WG2LC:
draft-ietf-geopriv-held-identity-extensions-00.txt
	
	
	Ray,
	
	You won't find too much sympathy in the IETF for not wanting to
upgrade.  We're talking about computing devices, not too many deployed
that don't require upgrades.  I believe the black-jack game on my iPhone
has been upgraded at least 4 times in the 8 month life of the phone (and
the OS at least 3 times).
	
	OBO is, IMO, from an end-user pov, a privacy disaster waiting to
happen.  But, with proper authentication and authorization it might be
doable within the constraints of GeoPriv.
	
	-Marc-
	
	On 9/17/09 12:05 PM, "Ray.Bellis@nominet.org.uk"
<Ray.Bellis@nominet.org.uk> wrote:
	
	

		
		> I'm also not sure that NENA is asking for
third-party/OBO, I believe it's
		> SPs asking for it.  NENA simply wants location
included with call setup.
		
		Getting location included with call setup requires
software and/or firmware updates to every (mobile) SIP device on the
planet. 
		
		NICC therefore wants OBO, because in the short-to-medium
term it's the only way to get location without requiring those device
updates. 
		
		OBO can work now, with the only pre-requisite being
deployment of LIS's on each IP access network.  Those LIS's will be
required for first party queries anyway, for those devices that don't
have GPS capablity. 
		
		Ray