Subject: [Geopriv] Making decisions at Prague....

From: "Moore, Lyn E" <[email-masked]>
Date: Thu, 15 Mar 2007 08:58:32 +1100

Hi All
 
As a long-time "watcher" of GeoPriv, I'd like to make a few observations
for you all to think about whilst you are in Prague...
 
1.  The IETF is here to specify protocols.  Not to conduct faction
fighting.  No standard protocol for location acquisition has been
produced after 1 year of chit-chat and, sometimes, personal abuse
between GeoPriv members.  This is highly unprofessional behaviour.
 
2.  I work for the largest telco in Australia (Employees: 50000, service
area: Australia, Hong Kong and New Zealand).  Telstra is a full-service
provider - PSTN, ISP, VSP, access networks (ADSL, cable, WiFi, 2GSM,
3GSM), content provider, enterprise service provider and more.   I
require a solution now for IP Location - both emergency calling and
general use.  I want to deploy one solution not a NENAesque solution for
emergency calling and another solution to provide location for the fixed
access networks. 
 
3.  Telco's build networks based on ESTI 3GPP/TISPAN, ADSL Forum, OMA
standards etc.  To have a useful location acquisition protocol, it needs
to work on and with these standards.  If not, any solution you come up
with will be ignored as impractical.  This is not a case of the old
"net" vs "bell-head" jibe that reappeared this week, but this is
reality.  The IP networks out there are run by telcos.
 
4.  Telstra, by Act of Parliament, also runs the Australian PSAP.   As
Australia only has the one PSAP, our requirements for routing emergency
calls are simpler than elsewhere.  However, the hype surrounding the
emergency calling issue coming from North America and Europe is leading
the regulators to believe commercial grade solutions are available.
This puts pressure on.  It is hard to explain that there are many draft
protocols, but no standard.  We will be required by the regulators to
have a solution for emergency calling very soon.
 
5.  I want someone to categorically tell me why HELD is "not suitable
for the internet" as alleged earlier this week.  Is this because it
doesn't scale, isn't good technically, doesn't provide all the necessary
functionality OR is it because  Andrew Corp haven't done their politics
correctly or aren't in the right clique ?  
 
6.  I have asked a number of the usual telco equipment vendors, some of
which you represent, and so far the Andrew Corp solution is the only one
I can see that is possibly commercially viable.  Is this the real issue
?  Is this forum delaying standardisation of HELD for commercial reasons
?  I hope not.
 
Sorry for being so blunt, but it needed to be said.
 
So please try and come to some form of consensus in Prague.  I need
commercial solutions, which means you guys need to specify protocols.

Regards
Lyn Moore
 
Senior Emerging Technology Specialist
Telstra - Chief Technology Office
23 /242 Exhibition Street, Melbourne.
AUSTRALIA
 
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Mar 2007 18:34:35 -0400

On Mar 14, 2007, at 5:58 PM, Moore, Lyn E wrote:
> 6.  I have asked a number of the usual telco equipment vendors,  
> some of which you represent, and so far the Andrew Corp solution is  
> the only one I can see that is possibly commercially viable.

Since bluntness is the theme of the day, just how did you, they, or  
anybody reach such a conclusion?  What were the qualifications and  
requirements for reaching that conclusion?  And did you/they evaluate  
RELO, and how did it stack up? (I'll assume we're sticking to the L7  
solution space and also disregard the proposal named LCP since I'm  
personally on record as considering it unimplementable as  
specified).  And since HELD has gone through many iterations itself,  
how did you evaluate it as a moving target?

>   Is this the real issue ?  Is this forum delaying standardisation  
> of HELD for commercial reasons ?  I hope not.

I sincerely hope not as well.  My job would certainly be easier if  
this could be settled tomorrow.

But I'll give you my perspective.  HELD was first introduced as a  
protocol specification, and it did a lot of things.  Let me stress  
that -- a lot of things! What was never introduced in clear terms to  
the working group were any requirements or goals or needs.  We were  
basically asked to ratify a rather lengthy protocol specification  
that we did not understand.  To top it off, there were subtle but  
important distinctions in terminology that made communication  
difficult (e.g. LIS vs. LS).  Given that part of our task is the  
privacy of location information (i.e. the PRIV of GEOPRIV),  
understanding of the features is required.

Since the introduction of HELD, we've had to dissect the various  
areas of function.  So far we have L-by-R, LCP, OBO, and location  
signing.  I hope we are at the end of that list, because each is a  
complicated subject.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 18:48:02 -0500

Hi everyone,

I think the tension here is to be expected. The WG wants to thoroughly
debate the issues that are associated with a protocol like HELD - which
came to the table pretty much fully formed and without having been on
the radar previously. The industry players who were involved in the
formulation of the requirements for some time previously are now feeling
the pinch because a couple of years later there still isn't a
referencable specification and both the market and the regulatory
environment have continued to move forward. I'm still waiting on the FCC
to "drop the other shoe" with respect to their mooted future rulings in
their last docket. It's already happened in Canada.

To be fair to HELD, the number of changes in the last two years hasn't
been that great. The most significant one came early when its coupling
with HTTP was considered undersirable. The next draft decoupled it from
the session/transport and separate drafts for BEEP versus HTTP bindings
were provided.

Unfortunately, I think there are a number of additional features to be
discussed. Here is the list of things that HELD supports - and all of
which have been raised to one degree or another in the past months. It's
extensive but I think HELD is no more or less than it needs to be -
acknowledging that other WG members haven't satisfied themselves of
this.

Obviously I'd really like it if HELD could be taken to WG item status
and the fine-tuning of the features could still continue. That would
give the industry a referencable draft without being the ultimate
commitment to the package.

1.    Works over IP (also gets referred to as L7)

2.    Represents location using PIDF-LO

3.    Supports Geodetic and/or Civic address location

4.    Permits acquisition of a jurisdictional-specific civic form for
emergency services appropriate to access jurisdiction

5.    Client can specify preference for geo, postal civic, and/or
jurisdictional civic in request

6.    Supports the acquisition of device identity independent location
references
  a.    Location reference request can specify life-time of location
reference
  b.    Client can request extension or termination of location
reference   life-time
  c.    LIS is able to apply client authentication/authorization on the
dereference interface
  d.    The acquisition protocol is be able to be used as the
dereference protocol

7.    Permits client to provide geopriv privacy rules/preferences with
the expectation of them being applied during dereferencing

8.    Location requests can include "response time" QoS against which
accuracy may be traded off

9.    PIDF-LO signature can be requested for acquired location
  a.    Signature can be used to determine whether location information
has been changed since signature was generated 
  b.    Signature can be used to verify the time-period of validity of
the location information 
  c.    Signature can be used to discriminate between a PIDF-LO provided
for one LIS client versus another 
  d.    Signature can be used to determine an organizational/operator
identity associated with the specific LIS 

10. Location request can include a nominal location which can be tested
by the LIS against the LIS-determined location - This is location
assertion.
  a.    The LIS communicates the result of this assertion test to the
client 
  b.    If requested, the LIS is able to sign the client-provided
location in the event of a successful assertion test 

11. The protocol does not preclude an appropriately
authenticated/authorized client from acquiring location or location
reference on behalf of a target device. - OBO

12. The protocol supports the use of extensible parameters defining
target device identity to be included in a location request - used for
OBO and LIS-LIS communication.

13.A LIS may use HELD to act as a location acquisition client to another
LIS
  a.    A LIS acting as a LIS client shall be able to use identity
extensions to facilitate target device identification 

14. The protocol supports a mechanism by which the client and LIS can
establish common location measurement and determination capabilities,
including additional location protocol capabilities, and utilize those
capabilities in the determination of location. Allows a the device and
LIS to negotiate common protocol support - e.g. SUPL for assisted-GPS,
RFID beacon scanning for enterprise/muni, LLDP for switch port ID...

---------

So - that's quite a list.

The only other feature that I can think of as having been discussed is
the "location reporting" function. This is mooted in RELO. The device
can ask for a location reference and the reference actually points to a
SIP subscribable service that will periodically push location
information to the dereferencer. I think this makes sense as a service
for a LIS to provide (it hasn't come out of the emergency services
requirement soup but it's certainly got precedents in OMA MLP and 3GPP
location service models).

We'd certainly be happy to add HELD support for requesting a reference
to such a reporting service.

I know this doesn't actually make the list any shorter but I think we're
seeing that a network-embedded location service may actually need to be
quite feature rich.

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 15 March 2007 9:35 AM
To: Moore, Lyn E
Cc: [email-masked]
Subject: Re: [Geopriv] Making decisions at Prague....

-andy

------------------------------------------------------------------------------------------------
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]

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 Mar 2007 18:59:49 -0500

> to such a reporting service.

[AJW] Actually HELD does not preclude returning a SIP URI for just this
purpose.
When you request a context using HELD you get a list of URIs supported
by the LIS that all point to the same context.

[AJW] This is already supported for free.

> signing.  I hope we are at the end of that list, because each is a
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Mar 2007 22:05:03 -0700

>
>1.  The IETF is here to specify protocols.  Not to conduct faction fighting.  No standard protocol for location acquisition has been produced after 1 year of chit-chat and, sometimes, personal abuse between GeoPriv members.  This is highly unprofessional behaviour.

I don't think anyone would disagree that the situation has brought out more vitriol
than is healthy, and I hope that those of us in Prague can find ways to move
past that. 

You should realize, though, whatever your length of observation,
that both sides in this feel pushed.  The GeoPRIV working group was chartered
a fair amount of time ago with a strong focus on the privacy aspects of
location; the acronym doesn't appear in the working group's name by
accident.  It has produced a number of RFCs which specify the management
and distribution of location objects and the presence-based architecture
is actually very strongly coupled to SIP's idea of presence (and therefore
to the IETF's idea of a VoIP infrastructure).

Not just in relation to L7, but in relation to Radius, DHCP, and other protocols,
the IETF has struggled with how to handle the tension between the provision
of location objects (and their privacy characteristics) and the provision
of the location information necessary to build those objects.  Despite the
fact that location information has many of the same privacy concerns, the
working group has agreed in the past to allow the privacy concerns to take
second fiddle where the deployment argued for a location provisioning
mechanism that could not easily carry the full location object.  But it did
so with a serious amount of concern that the location information was
protected to the extent possible, and with trepidation that this was sending
the wrong message to the community about how best to protect the
privacy of the user's location.  Jon Peterson said some prescient (and dire)
things to me on this topic when the DHCP draft was approved by the IESG;
I happen to think that we would have had other problems without that
draft, but he was clearly right that the message it sent has in some ways
overwhelmed the original focus of GeoPRIV.

HELD appears to have a very different view of the privacy characteristics
of location, and it seems to come from a point of view that does not see
the user control inherent in the presence infrastructure as critical to
the overall system.  Read again this introduction to held-identify-extensions:

   A basic premise in HELD is that the source IP address of the location
   request message can be used by the LIS to identify the requesting
   Target, and that this identity can be used with other contextual
   network information to provide a physical location for the Target.
   In many network deployments this premise holds true, but in some
   network deployments additional identifiers are required to identify
   the Target at different points throughout the network, or they may
   assist with speeding up location determination.

   The base HELD schema was designed with extensibility in mind and the
   assumption that IP address may not always be enought to identify a
   Target.  The HELD identity extensions schema is made up of a number
   of discrete element blocks that can included into the HELD
   locationRequest, createContext and updateContext messages.  These
   elements can then be used by the LIS to identify the Target closer to
   the edge of the network, for example a MAC address or DHCP client-
   identifier, or to identify an element that has a closer relationship
   with the target, for example LLDP switch and port information.  The
   identity extension elements have been desgined to work across a range
   of existing and emerging technologies.  It is envisaged that while
   this schema is not exhaustive, it will address many of the perceived
   deployment solution.  It is further envisaged that extensions to this
   schema will be necessary as new identifiers are created or required.

The kind of identity binding these discuss are very serious ties of user
identity to location, and are exactly the kind of thing that GeoPRIV
started out to protect. As you read any of the HELD documents, you
get a strong sense that the aim is to use the location information model
rather than the location object model throughout (though there are syntactic
similarities with the location object model).  That's a very basic
difference of assumption--about the role of the network, the user, and
the location. 

The use of emergency services as a driving use case for this has caused
many conversations along the lines of "but we throw out the usual rules
to get the best information we can to a PSAP".  But  it is very different
to start from the assumption that the user is in control of the distribution
of their location and relax specific rules when you need to get the job
done versus starting from the assumption that the network is in control of
the distribution of the user's location and whatever user identity it
has.  Many of the point arguments we have had in the past week, it
seems to me, go back to that difference of assumptions.  We argue
about simless phones and specific regulatory mandates, when the
real tension is far deeper.  That is why your statement below,
which implies putting forward a single system for emergency calling
and general use, concerns me.  I think if you started from the
basic geopriv assumptions and moved from there, what you would end
up there would be reasonably good (and you could do that today using
signed location objects, presence, and SIP).  If you start from where
James and Martin seem to start from, I believe you will end up with
a location information system that has little to no user control;
that has to concern me.

You ask if the Andrew folks haven't got their politics right.  First,
we do try to treat folks as individuals rather than by corporate
affiliation here, but I assume you mean Martin and James. If you mean,
are they not buying the right folks beer or horse-trading favors, then no,
that's not the problem.  The problem is their work appears to ignore
the chartered goal of the working group.  They argue (at times very
convincingly) that the goals of the working group are incompatible
with specific deployments, specific aims like emergency calling, or
the fiscal realities of presuming that large networks will deploy
expensive equipment to get this when that equipment's usual
use is covered elsewhere.  I am sure they are deeply frustrated by what
can easily look like a willingness to ignore those realities.  I can
assure you that folks don't want to ignore them (though they may
want demonstrations they are true).  They want to understand if there
are ways to meet the goals of the group *GeoPRIV* in those contexts.
If not starting from the chartered goals of the working group isn't
getting their politics right, then yes, that is a problem.

That's just my opinion on the tension, obviously, and Martin, James and
I already plan to sit down in Prague.  Possibly they will there convince
me that I have the wrong end of the stick.  I hope, though, that the
end goals remain the same:  that we are working toward a system
that continues to recognize that "while the formatting and transfer of such information
(location) is in some sense a straightforward process, the implications of doing it,
especially in regards to privacy and security, are anything but." and that
continues to value the user's privacy and control--even if it must
under some circumstances put other goals like emergency service
higher.

Just my two cents,
		regards,
				Ted Hardie

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Mar 2007 11:22:31 +0100

Hi Lyn,

I agree with you that we need to make progress and I don't want to blame 
anyone for causing delays.

Since you showed up on the mailing list, let me ask you a question based 
on my recent proposal.
As you said there is only a single PSAP in Australia. My proposal would 
be ideal for such a country, namely: As an operator you would make 
location information at the country level granularity available to the 
end host. Then, you would also provide the end host with a 
location-by-reference. This reference points to the precise location of 
the end host and only needs to be resolved by the PSAP.

Does this make sense to you?

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 15 Mar 2007 16:13:14 -0400

Hi Ted,

About user-control, network-control and the emergency context, I think a few points are worth considering:

- RFC-3693 allows for a jurisdiction (local, national or otherwise) to share the role of the Rule Maker and therefore, to contribute explicit Privacy Rules for some involved Location Servers (those under his jurisdiction, for example) to be applied when providing a Location Object to a Location Recipient (which obviously could include the jurisdiction itself).

- In the context of emergency calls or other life-threatening situations, some jurisdictions allow for the emergency services provider to use whatever (relevant) private/sensitive information they have at their disposal, such as the caller's identity and location, to assist the person in danger and this, without explicit consent of the caller. This is the case for Canada.

- Some emergency providers, as Guy and others mentioned, are about to implement support for emergency calls on VoIP within their jurisdictions. The reality is that not all emergency VoIP callers will have access to a "location-capable" VoIP device in the short term. Therefore, it is envisioned that in a transition phase, emergency providers could acquire the VoIP caller's location on their behalf (which is certainly not without its challenges). This is in line with the jurisdictions I just described above, but might not be suitable for other jurisdictions.

- Some emergency providers (and their associated PSAPs) might want to be able to distinguish a true location from a prank one and therefore might want to restrict location forgery.

In my opinion, these observations are not necessarily in opposition with preserving user control, as the user totally controls that his location information and maybe his identity are being used in a life- (probably his own) threatening situation. HELD happens to address this emergency context very well. This situation is very real and some have to deal with it now.

However, as I understand it, HELD is not restricted to this particular use case as it also applies to the "location-capable" endpoint model. That is, where the user has explicit and direct control over the distribution of his location.

I hope this helped expose some subtleties of the user-control versus network-control perspective.

Jérôme

-----Message d'origine-----
De : Ted Hardie [mailto:[email-masked]] 
Envoyé : 15 mars 2007 01:05
À : Moore, Lyn E; [email-masked]
Objet : Re: [Geopriv] Making decisions at Prague....

Just my two cents,
		regards,
				Ted Hardie

---

From: "Moore, Lyn E" <[email-masked]>
Date: Fri, 16 Mar 2007 13:43:07 +1100

Thanks for your reply Ted (and others)

At least I now have some idea to the underlying source of your
differences in opinion.  Detailed technical discussion can easily
submerge the reasoning behind issues.  I am pleased to see that those
who replied to my intentional bombastic email(sorry for that - I was
trying to make you all see how your discussions could be interpreted)
provided sound reasoning for me to consider further.  

Good Luck in Prague
Cheers
Lyn

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Thursday, 15 March 2007 4:05 PM
To: Moore, Lyn E; [email-masked]
Subject: Re: [Geopriv] Making decisions at Prague....

I don't think anyone would disagree that the situation has brought out
more vitriol than is healthy, and I hope that those of us in Prague can
find ways to move past that. 

You should realize, though, whatever your length of observation, that
both sides in this feel pushed.  The GeoPRIV working group was chartered
a fair amount of time ago with a strong focus on the privacy aspects of
location; the acronym doesn't appear in the working group's name by
accident.  It has produced a number of RFCs which specify the management
and distribution of location objects and the presence-based architecture
is actually very strongly coupled to SIP's idea of presence (and
therefore to the IETF's idea of a VoIP infrastructure).

Not just in relation to L7, but in relation to Radius, DHCP, and other
protocols, the IETF has struggled with how to handle the tension between
the provision of location objects (and their privacy characteristics)
and the provision of the location information necessary to build those
objects.  Despite the fact that location information has many of the
same privacy concerns, the working group has agreed in the past to allow
the privacy concerns to take second fiddle where the deployment argued
for a location provisioning mechanism that could not easily carry the
full location object.  But it did so with a serious amount of concern
that the location information was protected to the extent possible, and
with trepidation that this was sending the wrong message to the
community about how best to protect the privacy of the user's location.
Jon Peterson said some prescient (and dire) things to me on this topic
when the DHCP draft was approved by the IESG; I happen to think that we
would have had other problems without that draft, but he was clearly
right that the message it sent has in some ways overwhelmed the original
focus of GeoPRIV.

HELD appears to have a very different view of the privacy
characteristics of location, and it seems to come from a point of view
that does not see the user control inherent in the presence
infrastructure as critical to the overall system.  Read again this
introduction to held-identify-extensions:

The kind of identity binding these discuss are very serious ties of user
identity to location, and are exactly the kind of thing that GeoPRIV
started out to protect. As you read any of the HELD documents, you get a
strong sense that the aim is to use the location information model
rather than the location object model throughout (though there are
syntactic similarities with the location object model).  That's a very
basic difference of assumption--about the role of the network, the user,
and the location. 

The use of emergency services as a driving use case for this has caused
many conversations along the lines of "but we throw out the usual rules
to get the best information we can to a PSAP".  But  it is very
different to start from the assumption that the user is in control of
the distribution of their location and relax specific rules when you
need to get the job done versus starting from the assumption that the
network is in control of the distribution of the user's location and
whatever user identity it has.  Many of the point arguments we have had
in the past week, it seems to me, go back to that difference of
assumptions.  We argue about simless phones and specific regulatory
mandates, when the real tension is far deeper.  That is why your
statement below, which implies putting forward a single system for
emergency calling and general use, concerns me.  I think if you started
from the basic geopriv assumptions and moved from there, what you would
end up there would be reasonably good (and you could do that today using
signed location objects, presence, and SIP).  If you start from where
James and Martin seem to start from, I believe you will end up with a
location information system that has little to no user control; that has
to concern me.

You ask if the Andrew folks haven't got their politics right.  First, we
do try to treat folks as individuals rather than by corporate
affiliation here, but I assume you mean Martin and James. If you mean,
are they not buying the right folks beer or horse-trading favors, then
no, that's not the problem.  The problem is their work appears to ignore
the chartered goal of the working group.  They argue (at times very
convincingly) that the goals of the working group are incompatible with
specific deployments, specific aims like emergency calling, or the
fiscal realities of presuming that large networks will deploy expensive
equipment to get this when that equipment's usual use is covered
elsewhere.  I am sure they are deeply frustrated by what can easily look
like a willingness to ignore those realities.  I can assure you that
folks don't want to ignore them (though they may want demonstrations
they are true).  They want to understand if there are ways to meet the
goals of the group *GeoPRIV* in those contexts.
If not starting from the chartered goals of the working group isn't
getting their politics right, then yes, that is a problem.

That's just my opinion on the tension, obviously, and Martin, James and
I already plan to sit down in Prague.  Possibly they will there convince
me that I have the wrong end of the stick.  I hope, though, that the end
goals remain the same:  that we are working toward a system that
continues to recognize that "while the formatting and transfer of such
information
(location) is in some sense a straightforward process, the implications
of doing it, especially in regards to privacy and security, are anything
but." and that continues to value the user's privacy and control--even
if it must under some circumstances put other goals like emergency
service higher.

Just my two cents,
		regards,
				Ted Hardie