Re: [Geopriv] HELD: user-configured data

James Winterbottom <a.james.winterbottom@gmail.com> Wed, 29 April 2015 16:49 UTC

Return-Path: <a.james.winterbottom@gmail.com>
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 D9FA11A88A4 for <geopriv@ietfa.amsl.com>; Wed, 29 Apr 2015 09:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 pMG9NL64-cLd for <geopriv@ietfa.amsl.com>; Wed, 29 Apr 2015 09:49:12 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AF01A8978 for <geopriv@ietf.org>; Wed, 29 Apr 2015 09:49:08 -0700 (PDT)
Received: by pacyx8 with SMTP id yx8so32849737pac.1 for <geopriv@ietf.org>; Wed, 29 Apr 2015 09:49:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6zqOgj12HADnTVPBsE9IrFiQxqFCNjN2xwd2TMAWzeo=; b=C3k7Y/2ZjJ/LWf73h6K8KstOMDGjF5so7NWhN/rGASfEXWRk4UPM86gdqrXFXSR0ta yimYev/vUSa/hDZdJQrNO9mg87NlIDB9iEfEU0D0Z+V4YXcoYH+gvhrodaqyley6wxMO pyXIayISx+NYGkDSApqamt5rLqayLdZx3zEtzOLPZf/xsnZdJMP+KCPdIsg+vZ+mPHa8 sZBn5NqQxF4H2o8+IbXgLG80sjr4TJ0bV9eK/c12xbcppzSM6wtAiQ+saUPsL+OOW5xu yLOPsr+NVh4NDLNX8GvNZpmAWZvGxs3jHx5HdqYpOI3bPfhkIUfLXAS7O93lQdGXtsM+ ngtw==
X-Received: by 10.68.203.202 with SMTP id ks10mr27722967pbc.112.1430326148263; Wed, 29 Apr 2015 09:49:08 -0700 (PDT)
Received: from [192.168.1.11] (124-169-21-47.dyn.iinet.net.au. [124.169.21.47]) by mx.google.com with ESMTPSA id nj7sm25859623pbc.36.2015.04.29.09.49.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Apr 2015 09:49:07 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: James Winterbottom <a.james.winterbottom@gmail.com>
In-Reply-To: <E6A16181E5FD2F46B962315BB05962D07D338634@fcc.gov>
Date: Thu, 30 Apr 2015 02:49:03 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <83066A48-F97B-423E-BD14-9D42313E45EE@gmail.com>
References: <E6A16181E5FD2F46B962315BB05962D07D336F45@fcc.gov> <, > <CABkgnnWcLErqa4b6CGUKgLVuc6HDQFdiR9nFZnzFDX20G=C3YA@mail.gmail.com> <E6A16181E5FD2F46B962315BB05962D07D337042@fcc.gov> <30BDAF1D-6F50-4053-AA7F-818BD6E68043@gmail.com> <E6A16181E5FD2F46B962315BB05962D07D3376E1@fcc.gov> <61D3E84D-765D-45C3-8A75-7DB5A3473DF0@neustar.biz> <E6A16181E5FD2F46B962315BB05962D07D338634@fcc.gov>
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/geopriv/qBF0aWhgw-bJuEX1KzGxhpcKIp4>
Cc: "geopriv@ietf.org" <geopriv@ietf.org>, "Rosen, Brian" <Brian.Rosen@neustar.biz>
Subject: Re: [Geopriv] HELD: user-configured data
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: <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: Wed, 29 Apr 2015 16:49:14 -0000

Hi Henning,

Just so I am 100% sure on what you are querying/asking about.
A device is able to use HELD to update its location in a LIS and the LIS would then validate the location and store it against the IP address of the device?

Is there an assumption that from that time forward that the location is statically bound to that IP address?
So, if the initial device, device-X, pushed something that bound IP address ABC to location EFG that this remains in the LIS. Then if device-X disconnects from the network, device-Y connects and allocated IP address ABC that it will then be at location EFG? The net result being that the LIS is populated via crowd-sourcing?

If the location could be different each time address ABC is allocated then I am not really sure why the device wouldn’t just keep the location in the device and send a PIDF-LO at INVITE or REGISTER time.

I am not necessarily opposed to the idea because I think I  only half understand the use case.

Cheers
James



> On 30 Apr 2015, at 1:40 am, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; wrote:
> 
> Brian,
> 
> The "UA provider = service provider" may have been true in the past, but you are familiar with efforts on VRS to create a uniform (multi-provider) VRS SIP UA. Yes, there's a reason for my question...
> 
> It would be really nice if a user didn't have to update multiple location databases manually, each via their own web page.
> 
> Henning
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] 
> Sent: Saturday, April 25, 2015 10:34 AM
> To: Henning Schulzrinne
> Cc: James Winterbottom; geopriv@ietf.org
> Subject: Re: [Geopriv] HELD: user-configured data
> 
> The i2 mechanism is using a web page.
> 
> It seems you are arguing that it's more likely the user would update her address on a phone device using something other than a browser interface than using a computer or a browser interface on the device.  That seems unlikely to me.  Further, in the VRS case, the device is provided by the same entity as the LIS provider, so even if it was a non-browser interface, it could update the existing database.
> 
> The prompt to do it seems independent of the mechanism to do the update.
> 
> Brian
> 
>> On Apr 25, 2015, at 8:49 AM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; wrote:
>> 
>> James,
>> 
>> I'm struggling with the problem that deployment of LIS by ISP has been slow (and this is more glacier-slow than snail-slow). Thus, I'm afraid that user-provided location will be with us for quite a while, for landline and nomadic devices.
>> 
>> In my particular use case (VRS), faking locations seems less likely since the caller is a known entity.
>> 
>> In addition, there is some ability to validate the rough location by IP address.
>> 
>> Besides a custom web page, we don't seem to have any good standards-based options at the moment. I'd like to be able to automate the process a bit, so that the UA can detect changes in network attachment point and prompt the user for new location data.
>> 
>> Henning
>> 
>> ________________________________________
>> From: James Winterbottom [a.james.winterbottom@gmail.com]
>> Sent: Friday, April 24, 2015 4:16 AM
>> To: Henning Schulzrinne
>> Cc: Martin Thomson; geopriv@ietf.org
>> Subject: Re: [Geopriv] HELD: user-configured data
>> 
>> I guess that this would ensure that location was "valid", but doesn't it open the system up to the "Where would I like to be today" issue that is impacting i2 to some extent?
>> The LIS is supposed to provide some kind of assurances on the location it provides, if it can be independently user-populated it kind of feels like this aspect of the LIS is going away.
>> 
>> Cheers
>> James
>> 
>> 
>> 
>>> On 24 Apr 2015, at 8:43 am, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; wrote:
>>> 
>>> I'm not wedded to the method at all, but that was the only one that seemed close... A validation query via LoST might be a good option (i.e., first LoST, then HELD).
>>> 
>>> ________________________________________
>>> From: Martin Thomson [martin.thomson@gmail.com]
>>> Sent: Thursday, April 23, 2015 6:32 PM
>>> To: Henning Schulzrinne
>>> Cc: geopriv@ietf.org
>>> Subject: Re: [Geopriv] HELD: user-configured data
>>> 
>>> On 23 April 2015 at 14:36, Henning Schulzrinne 
>>> <Henning.Schulzrinne@fcc.gov>; wrote:
>>>> Can we use a model similar to RFC 7105 for updating user-configured (civic) location data in VoIP scenarios?
>>> 
>>> 
>>> 'twould require definition of a new measurement type that used the 
>>> civic address schema.
>>> 
>>> The success response would likely turn into an echo of the address; 
>>> failure would not include the information.  There wouldn't be any way 
>>> to annotate that with extra information about what went wrong in the 
>>> same way that recent additions to LoST might.
>>> 
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>> 
>> 
>> 
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
> 
>