Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 16 Apr 2007 12:14:26 -0400

Right.  Good summary.

However, because at least some networks have to get through Pay to Play,
we need to provide mechanisms that work.  

The proposal (access networks that want pay to play must provide LbyR,
PSAP URI and dialstrings seems a workable solution to those networks.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Monday, April 16, 2007 12:10 PM
> To: Henning Schulzrinne; Rosen, Brian
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
do
> endpointcentric LCP without giving away the store
> 
> All very true I think. Providing location, in my view, is likely to go
> through the usual stages:
> 
> * Pay to play
> * Free as a competitive differentiator
> * Lowest common denominator and assumed as part of the access
> 
> I think the first phase is likely to prove quite short, to
non-existent,
> because of the cost of putting the billing overlay in.
> 
> Telephone companies didn't go into business to provide connectivity to
> emergency services but, eventually, they did it because it's a social
> service and society enforced the obligation - emergency calling,
> including location, became an assumed part of the bundle.
> 
> Similarly, the physics of the situation dictates it's the providers of
> broadband Internet access who can work out location (it's not like
it's
> a business conspiracy) and, eventually, this will become an assumed
part
> of the access bundle.
> 
> In cellular networks, the location request associated with initiating
an
> emergency call is called a "network initiated" request because the
> mobile switching center makes the request to the location server.
> However, most networks also support a form of request called
> "mobile-originated". It's quite likely that any suitably capable
handset
> can request location, unhindered, from those mobile networks. That's
> control plane - but SUPL permits SET-initated requests as well.
> 
> Providing location in cellular networks is probably the most network
> resource intensive form of this service. The precedent is in, really,
> that users will be able to get their location for free.
> 
> The business strategists that you refer to still need to go through
> their own processes and come to their own conclusions but I don't
think
> you'll be suffering stock option envy on this count Henning.
> 
> Cheers,
> Martin
> 
> 
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, 15 April 2007 12:52 AM
> To: Rosen, Brian
> Cc: [email-masked]; [email-masked]
> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
> endpointcentric LCP without giving away the store
> 
> [This is partially an editorial, but I'll get to solutions in the
> next message...]
> 
> My prediction is that the dream of untold riches to be mined from
> location information is largely just that.
> 
> In particular, I believe that the value of non-emergency location
> information for stationary devices in a residential setting is pretty
> close to zero. After all, users already know their home address and
> for pizza delivery and similar tasks, it doesn't much matter whether
> the address validates. Users will fix their address after the first
> cold pizza arrives.
> 
> As a practical matter, monetizing this information is going to be
> very difficult, particularly in European Union countries with strong
> privacy laws. A VSP is very unlikely to pay for location information,
> as it has no direct need for it. The local pizza parlor might find
> the information to be of interest, but the logistics are pretty
> daunting. Since you can't easily do per-use approval, as you can do
> with end system location, the pizza parlor would have to contact the
> various access providers and negotiate an arrangement. In addition,
> and most onerously, the pizza parlor would probably need to get
> individual approval from each potential customer to release this
> information to them. As a customer, why would I agree to release
> location information to every business, known and unknown, for
> purposes unknown? This can be fixed by uploading GEOPRIV policy to
> the access provider, but this requires heavy-duty machinery, as
> customers have to figure out which domains to include in that list.
> The likelihood that users will remember to add the pizza parlor's
> domain name to that list before calling for delivery is pretty slim.
> For a second delivery, the restaurant already has the correct and
> verified address, so it has limited additional value.
> 
> Let's assume for a moment that stationary-device location is indeed
> tremendously valuable. If so, we'll very quickly get a budding
> entrepreneur that will get the location from the access provider and
> then sell it, once, to the customer, for free use henceforth until
> the customer changes ISPs. Heck, depending on pricing, the customer
> might do it himself. I'd look forward to the having the access
> provider sue this enterprise for handing a customer their own street
> address. ("Yes, your honor, we don't allow this company to tell our
> customer where they live.")
> 
> Maybe Domino's will advertise "Get your free serving of location with
> our extra large pepperoni pizza!".
> 
> Thus, this whole hide-location-from-customer thing has the distinct
> feeling of cutting off your nose to spite your face or, more to the
> topic, of "I can't make VoIP pay for me, so I'm going to make it
> difficult for everybody else to offer services, too".
> 
> Location information is obviously valuable for mobile users, but I
> suspect that the consequence of making it difficult to get will
> simply increase the use of (unassisted) GPS and SkyHook, or BlueTooth
> on in-car navigation devices. (As navigation functionality gets
> integrated into mobile phones, this has to work even when there is no
> cell coverage.)
> 
> While I doubt that this argument will suddenly convince the brilliant
> strategists in telecom companies, at least I'll have a convenient
> place to point to for an "I told you so" five years from now, or
> maybe a good place to be proven wrong while others cash in their
> stock options.
> 
> Henning
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
>
------------------------------------------------------------------------
--
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
>
------------------------------------------------------------------------
--
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Mon, 16 Apr 2007 12:46:01 -0400

Using Martin's nice email to perhaps bring this thread back around to  
GEOPRIV and to quit dancing around the issue, has anyone actually  
asked us as part of requirements to hide location from the target?   
If so, who?  If not, why are we considering it?

-andy

On Apr 16, 2007, at 12:09 PM, Dawson, Martin wrote:

> I think the first phase is likely to prove quite short, to non- 
> existent,
> In cellular networks, the location request associated with  
> initiating an
> ---------------------------------------------------------------------- 
> --------------------------
> ---------------------------------------------------------------------- 
> --------------------------
> [mf2]
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 12:54:11 -0400

Well, there was the note from DT, for example.

It raised this very issue.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Monday, April 16, 2007 12:46 PM
> To: GEOPRIV WG
> Cc: ECRIT
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCP without giving away the store
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 12:53:46 -0400

> PSAP URI and dialstrings seems a workable solution to those networks.

This only works for stationary devices, barely, unless there's an  
event notification mechanism that updates that information,  
particularly the PSAP URL.

Otherwise, you have to rely on call-time queries, which significantly  
degrade reliability and performance. In that case, you're not  
providing a service that is equivalent and the customer pays for the  
provider's pay-to-play dreams with their life and property.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 16 Apr 2007 13:13:24 -0400

> Well, there was the note from DT, for example.

Refresh my caffeine-starved brain.  DT?

> It raised this very issue.

I'm getting the sense from this email thread that people do not  
believe it is a reasonable requirement for various reasons.  We are  
not obliged to accept everything thrown at us.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 13:25:09 -0400

http://www1.ietf.org/mail-archive/web/ecrit/current/msg03352.html

> Sent: Monday, April 16, 2007 1:13 PM
> To: Brian Rosen
> Cc: 'GEOPRIV WG'; 'ECRIT'

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 16 Apr 2007 13:32:03 -0400

> It raised this very issue.

And they stated they have a solution.

-Marc-

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 16 Apr 2007 13:35:27 -0400

I asked for it. I believe Otmar asked for it, also. I don't think I can
get my company to support this architecture if hiding location from
endpoints isn't an option.
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:46 PM
To: GEOPRIV WG
Cc: ECRIT
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to

-andy

> existent, because of the cost of putting the billing overlay in.
>

> it's a business conspiracy) and, eventually, this will become an 
> assumed part of the access bundle.
>
> an emergency call is called a "network initiated" request because the 
> handset can request location, unhindered, from those mobile networks. 
> That's control plane - but SUPL permits SET-initated requests as well.
>
> think you'll be suffering stock option envy on this count Henning.
>
> Cheers,
> Martin
>
>
> [This is partially an editorial, but I'll get to solutions in the next

> message...]
> As a practical matter, monetizing this information is going to be very

> difficult, particularly in European Union countries with strong 
> as it has no direct need for it. The local pizza parlor might find the

> information to be of interest, but the logistics are pretty daunting. 
> Since you can't easily do per-use approval, as you can do with end 
> system location, the pizza parlor would have to contact the various 
> access providers and negotiate an arrangement. In addition, and most 
> onerously, the pizza parlor would probably need to get individual 
> approval from each potential customer to release this information to 
> them. As a customer, why would I agree to release location information

> to every business, known and unknown, for purposes unknown? This can 
> be fixed by uploading GEOPRIV policy to the access provider, but this 
> requires heavy-duty machinery, as customers have to figure out which 
> domains to include in that list.
> then sell it, once, to the customer, for free use henceforth until the

> customer changes ISPs. Heck, depending on pricing, the customer might 
> do it himself. I'd look forward to the having the access provider sue 
> this enterprise for handing a customer their own street address. 
> ("Yes, your honor, we don't allow this company to tell our customer 
> where they live.")
>
> suspect that the consequence of making it difficult to get will simply

> increase the use of (unassisted) GPS and SkyHook, or BlueTooth on 
> in-car navigation devices. (As navigation functionality gets 
> place to point to for an "I told you so" five years from now, or maybe

> a good place to be proven wrong while others cash in their stock 
> options.
>
> Henning
>
> This message is for the designated recipient only and may contain 
> privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender immediately

> and delete the original.  Any unauthorized use of this email is 
> prohibited.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 13:35:59 -0400

Okay, let's look at this.

For fixed devices, the PSAP URI doesn't change often, the cached value is
very likely to be good.  However, it MIGHT change on short notice.  The call
time query fixes this, if it works.

For mobile devices, the endpoint may get a reference.  The REFERENCE doesn't
change.  It's good for a long time (probably as long as the carrier -
subscriber relationship holds).  If it gets a value, then it wants an update
when it moves beyond the PSAP boundary.  With a value, it queries LoST and
gets the boundary, then passes that to its location determination mechanism
and asks for a notification when it moves beyond that.

The above, of course, is fairly far from what IMS currently talks about, but
that is what the IETF ecrit/presence architecture would say.

If the access network plays cozy with the location, so it passes a reference
and a PSAP URI, then it needs a way to TELL the device when the PSAP URI is
no longer valid.  Perhaps we could define a SIP event package for this
purpose, so a LIS could notify an endpoint of a new PSAP URI when its
current location warranted that.  I suppose this is a presence thing, and
maybe we could tie this more strongly into the existing presence system.

Brian

> Sent: Monday, April 16, 2007 12:54 PM
> To: Rosen, Brian
> Cc: [email-masked]; Dawson, Martin; [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 13:48:47 -0400

We have such a mechanism, in progress at least: The SIP configuration  
framework (see http://tools.ietf.org/html/draft-ietf-sipping-config- 
framework-11). It supports SIP-based event notifications for  
configuration updates. As I said in an earlier message, re-inventing  
a subset of the configuration framework just for this purpose seems  
counterproductive.

---

From: Andrew Newton <[email-masked]>
Date: Mon, 16 Apr 2007 15:07:51 -0400

> endpoints isn't an option.

Barbara,

Can we get a clarification?  Is there a technical reason not to  
support this architecture?  If so, can we be informed as to what it is?

Also, by "this architecture", you are talking about an ECRIT  
architecture, not a GEOPRIV architecture, correct?

-andy