Subject: RE: [Ecrit] Comments on location-hiding-requirements-01

From: "James M. Polk" <[email-masked]>
Date: Sat, 01 Sep 2007 15:50:49 -0500

At 05:00 PM 8/31/2007, Winterbottom, James wrote:
>Yes, but we MUST choose an implementation such that the cost of
>implementing and it running doesn't exceed the revenue or costs of just
>giving location away for free in the first place.

This is a little bit over-dramatic. No service provided to your phone 
(pick any one you own and this applies) is free.  If you have a 
phone, you pay for _the_whole_service_. Why are folks insisting that 
Location be the first to be given away for free?

It clearly will not be - so get off this FUD, please!

If providing location to all subscribers costs 25 or 50 or 75 cents 
more a month, then all subscribers will pay that in their bill each 
month. That's the economic solution to this "problem".

> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Saturday, 1 September 2007 1:26 AM
> > To: 'Clive D.W. Feather'
> > Cc: [email-masked]
> > Subject: RE: [Ecrit] Comments on location-hiding-requirements-01
> >
> > Nah, the UA can't be fooled easily, especially if it does the dial
>string
> > interpretation.  The information can't easily be extracted along the
>way
> > if
> > the bcp guidelines are followed (the location would be encrypted).
> >
> > Agree that the ISP doesn't have a problem giving location to a PSAP.
> >
> > It has a problem giving it to a UA who can then use it for things
>other
> > than
> > an emergency call.  It has the same problem giving it to the ASP who
>runs
> > the calling network.
> >
> > This is not a security problem, it is an economic problem.  That
>doesn't
> > make it any less real, and we're going to have to solve it.
> >
> > Brian
> >
> >
> > > -----Original Message-----
> > > From: Clive D.W. Feather [mailto:[email-masked]]
> > > Sent: Friday, August 31, 2007 11:11 AM
> > > To: Brian Rosen
> > > Cc: 'James M. Polk'; [email-masked]
> > > Subject: Re: [Ecrit] Comments on location-hiding-requirements-01
> > >
> > > Brian Rosen said:
> > > > The answer to your question is that it is the fact that we ARE
> > requiring
> > > > location to be provided to the UA and/or the calling network that
> > makes
> > > IP
> > > > different.  In the current PSTN, the access network provides the
> > > location
> > > > directly to the PSAP.  In the Internet, we don't do that.
> > >
> > > Actually, I think that the point is that in the PSTN the location is
> > > provided *only* to genuine PSAPs - the access network provides that
> > > (unwritten) guarantee.
> > >
> > > I don't believe ISPs are objecting to providing location information
>to
> > > PSAPs. They're objecting to providing it to any Tom, Delila, and
>Harry
> > who
> > > can look enough like a PSAP to fool the UA or who can extract the
> > > information along the way.
> > >
> > > --
> > > Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20
>8495
> > > 6138
> > > Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870
>051
> > > 9937
> > > Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973
> > 377646
> > > THUS plc            |                            |
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
>
>------------------------------------------------------------------------------------------------
>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

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

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 01 Sep 2007 15:55:59 -0500

At 05:55 PM 8/31/2007, Winterbottom, James wrote:
>Perhaps less expensive is not the right term.
>We must not make the deployment cost of location hiding so exorbitant
>that no amount of charging for value added service can recoup the cost.
>
>I think we also need to be very mindful of who is paying for the
>location infrastructure in the first place.

that would be us, not them.

In fact, they will charge us for the cost of the infrastructure, then 
the start-up and ongoing operational costs of providing the service, 
then they will charge more for their profit margins - whatever they might be.

>These are people that I am
>talking about, and a solution that is best for them, the access
>providers, may well not be best for further down consumers such as
>net-based VSPs. I see the resolution of the problem for the VSPs as a
>different problem, which may require a different solution.
>
>Cheers
>James
>
> > From: Ted Hardie [mailto:[email-masked]]
> > Sent: Saturday, 1 September 2007 8:48 AM
> > To: Winterbottom, James; Brian Rosen; Clive D.W. Feather
> > Cc: [email-masked]
> > At 5:30 PM -0500 8/31/07, Winterbottom, James wrote:
> > >I meant the "we" in the IETF sense need to consider the potential
> > >operational costs in any solution we propose.
> > >
> >
> > Yes, but that does not follow from the second half of what you said:
> >
> > We can and should make sure that our protocols are as efficient as
> > possible, and that includes  a healthy sense of the operational costs
> > and realities of deploying them in the real world.  But that's not
> > a comparative.  Making the implementation of location hiding
> > less expensive than giving location away may well be impossible
> > in many deployments without artificially raising the cost of giving
> > it away.  And there's a naughty, naughty name for that.
> >
> >                               Ted
> >
> >
> >
> > >
> > >> From: Ted Hardie [mailto:[email-masked]]
> > >> Sent: Saturday, 1 September 2007 8:29 AM
> > >> To: Winterbottom, James; Brian Rosen; Clive D.W. Feather
> > >> Cc: [email-masked]
> > >> At 5:00 PM -0500 8/31/07, Winterbottom, James wrote:
> > >> Mind clarifying who the "we" is in the statement above?
> > >>
> > >>                    thanks,
> > >>                            Ted
> > >
> >
> >-----------------------------------------------------------------------
>--
> > -----------------------
> >-----------------------------------------------------------------------
>--
> > -----------------------
> > >[mf2]
> > >
> >
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 3 Sep 2007 01:22:08 -0500

To the best of my knowledge, and forgive me if it is different in the
US, existing location dependent routing services generally charge the
destination, and not the caller. That is Pizza Hut pay a great deal of
money to the SCP owner to support an LDR service map for their franchise
boundaries. What you are prescribing is having the end-point attached to
the network paying for this. I am merely stating that that is not the
only model, and may end up being an expensive model to pursue. I also
have severe reservation about it costing as little as you are suggesting
if you include the upfront costs to the infrastructure owners of initial
deployments.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Sunday, 2 September 2007 6:51 AM
--
--

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 3 Sep 2007 01:33:56 -0500

Ummm... I don't agree at all.
If the cost of your DSL service jumped by 60% over night to meet the
potential $60M outlay for infrastructure support, would you remain with
the access provider? I seriously doubt it.

Reality is that you will not be charged for the upfront costs, the up
front costs will be born by the access provider and will take time to
recoup. 

On a side note I find this hostile reaction to infrastructure providers
really quite absurd. 

Regards
James

> Sent: Sunday, 2 September 2007 6:56 AM
> To: Winterbottom, James; Ted Hardie; Brian Rosen; Clive D.W. Feather
> Cc: [email-masked]
> then they will charge more for their profit margins - whatever they
might
> be.
> > > >> >implementing and it running doesn't exceed the revenue or
costs of
> > > >just
> > > >> >implementing and it running doesn't exceed the revenue or
costs of
> > > >just
--
--

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 3 Sep 2007 02:26:59 -0500

Hi James (P),

I agree with you to the extent that I think, logically, the cost of
location infrastructure is best recouped through the subscriptions paid
for access. That is, IP location is an access service, so the cost of it
is wrapped up in that particular subscription.

We've got a bit of a legacy business model to deal with. Carriers who
have been providing location infrastructure for quite a few years (i.e.
cellular carriers) have typically charged third party applications for
access to the location of the subscribers. The Mobile Originated service
you refer to is routinely disabled in networks; only mobile-terminated
(or application originated) requests are supported. The subscriber opts
in, and may pay their subscription directly to a third party, but the
carrier gets their amortization by levying a charge on that third party
application provider. Agreed - the subscriber pays in the end.
Nevertheless, there hasn't been a model of charging subscribers simply
to have their access "location enabled"; there has only been a model of
charging for location applications.

I think this needs to change - and probably will eventually. The
paradigm that needs to be broken is the continued tendency to couple
access and service provision. What cellular carriers have really been
charging third party application providers for is the location of their
*service* subscribers. Applications query the gateway in the cellular
network for the location of a particular "MSISDN" - i.e. the phone
number, or actual subscriber identity. It's not based on the transient
TMSI that the device is known by in the network, or even the IMSI.

What cellular operators have actually been charging for is access to the
location of the subscribers to a *presence* service. These applications
are interested in the location of a particular individual as identified
by their subscriber identity. The home location register (HLR - a
presence server by any other name) is key to finding out how to proceed
with the location determination. In fact it's semantically identical to
getting a location reference. Back to today and considering Internet
services, the ability for a presence client to register the location
value/reference that it obtains from an arbitrary access network is key
to providing the equivalent capability.

*Service* providers, and this includes the cellular operators who are
evolving into IMS providers, will still be able to charge third party
applications for a location feed to their subscribers through the
presence service and based on the subscriber identity - not the
transient IP address. Currently, the access and the service aspects of
location are still conceptually aggregated - which creates pressure to
support something like location hiding with a view that location will
never be determined except for the purposes of an application known to
the access network provider. This is an invalid view - and also doesn't
scale for an Internet service model. Does Google-Navigation (I made that
up - but wouldn't be surprised if it exists in their lab; everything
else seems to :) ) need to have an authentication record and
relationship with every conceivable Internet access network in the
world? It's the same issue as VoIP emergency services; it doesn't work.

Operators who, for example, provide Internet access as well as, say, IMS
services will actually be able to charge access subscribers for the
general location service (location associated with my device's current
IP address)*and* service subscriber identity location (location
associated with my current IMS subscribers SIP identity). Pure Internet
presence service providers will only be able to charge for the latter;
pure Internet access providers will only be able to charge for the
former.

I, for one, will be quite happy to pay extra for my wireless Internet
(and wireline) access to have it provide me with the location service.
"Yes, please location-enable my WiMAX access for an extra $X per month".
For the price of that premium on my subscription, I want to be able to
get location for any application, and not just have it available to
emergency services. I'll register the location information with my
presence service(s) and applications that query that service based on my
presence identity will also be served; my presence service provider may
charge them for that privilege, but I won't see that.

What's new here, from the perspective of established operators, is the
idea of just charging for location capability as part of the access
service. Nevertheless, assuming they introduce that option, or if they
persist with trying to control access to location information by all
applications for some interim period, there still needs to be an option
to only have location information available for emergency services.

You are arguing that access network operators should not give their
subscribers the option of paying for the location service explicitly.
They should be given it, and charged for it, regardless. There aren't
too many new network services that get introduced that way. I don't
think we can insist that it be done this way. I think the important goal
is to get access networks location-enabled as quickly as possible so
that emergency services for VoIP work as quickly as possible. Playing
chicken with operators by deliberately not supporting "location hiding"
in the location protocols is not in keeping with that goal - and, I'm
sure, wouldn't work anyway. At best it will delay the availability of a
ubiquitous location service.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Sunday, 2 September 2007 6:51 AM
To: Winterbottom, James; Brian Rosen; Clive D.W. Feather
Cc: [email-masked]
Subject: RE: [Ecrit] Comments on location-hiding-requirements-01

> > > information along the way.
-------------------------
>this email is prohibited.
-------------------------