Subject: [Geopriv] coming to terms on location by reference

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Sep 2006 11:17:59 -0400

As John Schnizlein has noted in a message 
(http://www.ecotroph.net/~anewton/hypermail/geopriv/0607/2717.html), we have 
not truly come to consensus on location by reference within this working 
group.  The GEOPRIV working group has been presented with many individual 
submissions for both architectural considerations and concrete solutions. 
Additionally, this working group has discussed location-by-reference with 
regard to its component uses in location configuration protocols, location 
dereference protocols, and location conveyance protocols. As a working 
group, we are much further along in our understanding of 
location-by-reference than we were just 1 year ago. And as it stands, there 
are many who feel it is valuable, many who feel it is not, and many who have 
not given their opinions.  But it is now time for us to determine how we 
should move forward on location-by-reference, either accepting it as a 
whole, accepting it in limited form, or rejecting it entirely.

To that end, I offer the following inexhaustive list of observations on this 
topic:

1) Location-by-reference offers better efficiency where location of a target 
is not determined by the target and when the target wishes to convey its 
location.  It is more efficient because the target does not have to first 
retrieve the location in order to convey it.

2) Location measurement and determination (sighting) of a target by another 
element is of limited scope as self-determination methods such as GPS may 
offer greater accuracy.

3) Authentication of the dereferencer may have unintended consequences.  For 
example, a referent host may require authentication that could cause the 
failure of emergency call routing.  Therefore, location-by-reference may not 
appropriate or could even be harmful for certain use cases.

To further this discussion so that we may come to resolution on this topic, 
I welcome comments regarding the above as well as further observations.

-andy

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Sep 2006 10:51:29 -0500

1) The efficiency argument is an over-used red herring. Networks need to
work as fast as they need to and the Internet can be subject to
excessive delays that impact VoIP for many reasons. My observation is
that the consideration is primarily used as a rhetorical device.
Estimates of time appear to be dismissed as negligible or over-blown
depending on the point that people want to make.

2) Location by reference certainly doesn't obviate the ability to
utilize device-based measurements. To suggest this would be to make a
presumption about the nature of the sighting protocol. A location
reference implies a context and that context, from the LIS perspective,
includes the ability to exchange data with the device. I believe this
will be necessary. Autonomous GPS has very limited utility in indoor and
dense metro environments. A network which can provide GPS assistance
data based on knowledge of the approximate location of the device is
required to facilitate a GPS fix in these environments. This is the
standard way to obtain GPS location in the cellular domain. In any case,
the assertion that network based location determination must always be
more challenged than device determined location is an unsubstantiated
premise - and biased. Certainly a network determined location is much
better than that available from a device with no native location
measurement capability.

3) Authentication failure at the VPC, the emergency gateway, or indeed
at the call server may mean an emergency call cannot be made at all -
not even with default routing (which is at least possible without
location). Citing scenarios involving error conditions, failures, or
compromises through exploits are not valid arguments against any system.
If it were one could argue that the entire IP protocol suite and the
Internet should be disposed of as unacceptably risky.

As mentioned in a previous post of mine - the non sequitur one -
location by reference is of vital importance to the i2 architecture
defined by NENA. It is the only mechanism which will permit location
updates to occur for mobile IP access networks. If it is not just
useful, but has an absolutely defined application right now, why would
the IETF somehow attempt to forbid it?

To my previous post, we can also add the benefit that the application
provided with a location reference can ask for location in the desired
form - e.g. in jurisdicational/emergency civic, rather than postal
civic, or in geodetic. As opposed to the client device needing to divine
this information or provide every possible form of location in the
PIDF-LO to every application.

Cheers,
Martin

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Wednesday, 13 September 2006 1:18 AM
> To: [email-masked]
> Subject: [Geopriv] coming to terms on location by reference
> 
> 
> (http://www.ecotroph.net/~anewton/hypermail/geopriv/0607/2717.html),
we
> have
> are many who feel it is valuable, many who feel it is not, and many
who
> have
> To that end, I offer the following inexhaustive list of observations
on
> this
> 3) Authentication of the dereferencer may have unintended
consequences.
> For
> failure of emergency call routing.  Therefore, location-by-reference
may
> not

------------------------------------------------------------------------------------------------
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: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Sep 2006 17:59:56 +0200

Hi Andy,

based on the reference you provided this discussion refers to
* SIP Location Conveyance; and to
* the Geopriv Layer 7 design team work (access network <-> end host 
communication).

Consider the following scenario:

Location by SIP Proxy / Per Reference / in Header

    UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C

       |  SIP Message                |          |       |       |
       |---------------------------->|          |       |       |
       |                             | SIP Message      |
       |                             |----------------->|
       |                             | Location         |
       |                             | (ref./header)    |
       |                             |                  |
       |                             |                  |
       |                             |   Dereference    |
       |                             |<================>|
       |                             |                  |
       |                SIP Message                     |
       |<-----------------------------------------------|
       |                                                |
       |                                                |
       |                                                |

In the past we received a push-back regarding the usage of SIP proxies 
inserting a location object per value although technically not a problem.

If we don't want location per reference in such a scenario (and if we 
also do not allowed location-per-value inserted by a SIP proxy) then it 
seems that we have to get rid of this scenario as well.

Ciao
Hannes

PS: Another question that needs to be answered in this context: Is the 
reference pointing to a PIDF-LO or to plain location information? If it 
points to the former then the question about the content of the 
non-location related fields of the PIDF-LO appears again.

Andrew Newton schrieb:
> (http://www.ecotroph.net/~anewton/hypermail/geopriv/0607/2717.html), we 
> have not truly come to consensus on location by reference within this 
> working group.  The GEOPRIV working group has been presented with many 
> individual submissions for both architectural considerations and 
> concrete solutions. Additionally, this working group has discussed 
> location-by-reference with regard to its component uses in location 
> configuration protocols, location dereference protocols, and location 
> conveyance protocols. As a working group, we are much further along in 
> our understanding of location-by-reference than we were just 1 year ago. 
> And as it stands, there are many who feel it is valuable, many who feel 
> it is not, and many who have not given their opinions.  But it is now 
> time for us to determine how we should move forward on 
> location-by-reference, either accepting it as a whole, accepting it in 
> limited form, or rejecting it entirely.
> 
> To that end, I offer the following inexhaustive list of observations on 
> this topic:
> 
> 1) Location-by-reference offers better efficiency where location of a 
> target is not determined by the target and when the target wishes to 
> convey its location.  It is more efficient because the target does not 
> have to first retrieve the location in order to convey it.
> 
> 2) Location measurement and determination (sighting) of a target by 
> another element is of limited scope as self-determination methods such 
> as GPS may offer greater accuracy.
> 
> 3) Authentication of the dereferencer may have unintended consequences.  
> For example, a referent host may require authentication that could cause 
> the failure of emergency call routing.  Therefore, location-by-reference 
> may not appropriate or could even be harmful for certain use cases.
> 
> To further this discussion so that we may come to resolution on this 
> topic, I welcome comments regarding the above as well as further 
> observations.
> 
> -andy
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 12 Sep 2006 13:08:11 -0400

Thanks for trying to settle this issue which has nagged us for too long.

In my opinion, location by reference was defined when we accepted the notion
that location could be included in a presence notification.  If you do a SIP
SUBSCRIBE operation on a presence URL, you may get back a NOTIFY with a
PIDF-LO.

If that is not location-by-reference, I'd like to know why not.

I don't think the efficiency argument is particularly compelling.  It's
true, but not worth much.

I do worry about the 3rd party aspects of location by reference in the
emergency case.  We have tried pretty hard to make all of the mechanisms for
emergency fail safe, primarily by caching information in advance.  Location
by reference, generally speaking, spoils that effort.  If an endpoint gets a
reference instead of a value, short of doing the dereference itself, it
can't do a LoST mapping and can't cache its actual location.  When the
emergency comes, if the dereferencer does not have connectivity to the
reference host, it can't get location.

There is the positive argument that a location reference does have some
efficiency when you have a moving target.  Really, this is the presence
server argument, and it pretty much rings true, especially if there is more
than one watcher.  I'm pretty happy that location is part of presence.  

The real question in my mind is, is presence SUFFICIENT?  Do we need any
other protocols?  I think not.

Brian

> Sent: Tuesday, September 12, 2006 11:18 AM
> To: [email-masked]
> target
> another
> topic,

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Sep 2006 13:18:52 -0400

> seems that we have to get rid of this scenario as well.

I started a separate thread 2 weeks ago about proxy insertion of location by 
value, which is not the same thing as location by reference.  I purposefully 
have tried to separate these two items as they are separable and each can 
exist without the other.  So far, nobody has objected to proxy insertion of 
location by value.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Sep 2006 09:35:27 -0400

> true, but not worth much.

It also cuts various ways, depending on the assumptions. For example,  
if you assume that the UA has to do a LoST query just before the  
call, the LO has to traverse the air interface.

> reference host, it can't get location.

I agree that "atomicity" is a rather important concept here, both for  
availability and authentication.

In essence, I want to make sure that everybody that gets the call  
signaling can get location information, and those that don't get call  
signaling, generally can't. (There are exceptions to the latter  
statement, e.g., for passing information around at the PSAP and to  
first responders.)

Both are non-trivial to solve and, at the very least, require careful  
consideration.  (The availability issue is, at least in theory,  
impossible to solve since you can't guarantee that the holder of the  
location information will be available whenever the set of proxies  
and destination UAs are. Thus, we can only approximate this property.)

> other protocols?  I think not.

If you're willing to live with rather inefficient messaging, probably  
not. You do pay the price that you'll have a minimum of 2 message  
pairs (SUBSCRIBE-200 NOTIFY-200) for each retrieval, instead of one.

I'd also be careful with saying "just use presence", since  
subscribing to the AOR is probably not a good way to ensure the  
atomicity property above.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Sep 2006 13:37:31 -0400

Just a couple of clarifications:

> depending on the point that people want to make.

I'm not going to argue with the fact that network efficiency discussions are 
used a rhetorical device.  But in general, I do believe people making those 
arguments are sincere, as I have often been one of those people.  However, 
I'd like to point out that the observation I made regarding network 
efficiency was an argument in favor of, not against, using location by 
reference.

> Internet should be disposed of as unacceptably risky.

My observation was not that the authentication could be compromised. 
Instead, the observation was that the authentication would work and would 
deny location dereference thus causing the failure of emergency call routing.

> PIDF-LO to every application.

That's an interesting point, though my understanding of the requirement for 
the emergency case can be sumaarized as: "send everything you've got."

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Sep 2006 13:47:02 -0400

Henning Schulzrinne wrote:
> not. You do pay the price that you'll have a minimum of 2 message pairs 
> (SUBSCRIBE-200 NOTIFY-200) for each retrieval, instead of one.

For each retrieval or for each watcher?  And for in motion targets, wouldn't 
this be more efficient than polling by each watcher?

> I'd also be careful with saying "just use presence", since subscribing 
> to the AOR is probably not a good way to ensure the atomicity property 
> above.

Just for clarification, the atomicity property is vital to emergency calling 
but not other applications where location by reference would be valid, right?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Sep 2006 10:05:42 -0400

>> If you're willing to live with rather inefficient messaging,  
>> probably not. You do pay the price that you'll have a minimum of 2  
>> message pairs (SUBSCRIBE-200 NOTIFY-200) for each retrieval,  
>> instead of one.
>
> For each retrieval or for each watcher?  And for in motion targets,  
> wouldn't this be more efficient than polling by each watcher?
>

For each watcher. In general, polling is less efficient, but one has  
to be somewhat careful in making a blanket statement. For example, if  
there are no or inappropriate filters, the presentity could decide to  
send to send location updates (NOTIFY) whenever the geo coordinates  
change by any amount, even though the watcher might only care about  
occasional updates (for example, just before dispatch and as the  
first responders approach the general area of the caller or only if  
the location changes by more than a certain distance).

Thus, I'd qualify the statement as saying that notification is more  
efficient than polling if the notifier can accurately predict when  
the watcher needs the information. (As a side note, there's lots of  
discussion in SIMPLE as to the scaling of presence - and it is pretty  
clear that getting fine-grained updates on the everybody in your  
address book is far less efficient than occasionally polling people  
that you actually care about at the moment.)

For call routing (proxies), you'd presumably only do a single  
retrieval, even if the target is mobile.

> Just for clarification, the atomicity property is vital to  
> emergency calling but not other applications where location by  
> reference would be valid, right?
>

Vital in the word sense that your life depends on it, yes. The  
consequences for other applications may be more annoying than  
dangerous, but I suspect Domino's and AAA would be rather unhappy if  
a significant fraction of their calls would not provide location.  
(This is particularly annoying when you only find about the failure  
out after the customer has hung up - hard for AAA to call back the  
pay phone at the corner.)

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Sep 2006 17:14:31 -0500

So this is a statement in support of location by reference followed up
by a statement that it should only be the Rosen-preferred form of
reference.

To decouple the arguments then, I most certainly agree with the former.
For the latter, see all the arguments in the SIP conveyance discussions
to not restrain the form of the reference with prejudice. In particular,
the i2 architecture was not defined on the basis of *requiring* presence
to permit emergency calling to work. Talk about introducing unnecessary
elements in the emergency call process - despite claims to the opposite.
The LIS is not a presence server but the VPC needs to be able to query
it.

Cheers,
Martin

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 13 September 2006 3:08 AM
> To: 'Andrew Newton'; [email-masked]
> Subject: RE: [Geopriv] coming to terms on location by reference
> 
> that location could be included in a presence notification.  If you do
a
> SIP
> emergency case.  We have tried pretty hard to make all of the
mechanisms
> for
> by reference, generally speaking, spoils that effort.  If an endpoint
gets
> a
we
> > location-by-reference than we were just 1 year ago. And as it
stands,
> > there
who
on
> > element is of limited scope as self-determination methods such as
GPS
consequences.
may

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Sep 2006 17:45:47 -0500

1) I realized efficiency was being used in favor of
location-by-reference. I also offer the sincere view that I don't think
it's a valid argument for either position. There are many potential
deployment topologies and their associated preferences. Too often,
arguments are based on a specific presumption of use case and topology.
Location by reference is useful and the option shouldn't be excluded
from users because of such presumptions.

3) I think if authentication occurred and de-reference was still
subsequently denied then authentication can be said to have failed. The
intent is to authenticate and authorize. Either way it's citing a
failure in implementation as an argument against a mechanism.

On the flexibility of location-form supported by de-referencing, I would
agree with you if this was a ecrit discussion. However, I don't think
this discussion is just about the emergency application is it? Location
is an important element in a wide range of applications - which will
have their own application protocols. I believe that the most successful
application protocols are those that minimize the degree of dependence
on the device when it comes to acquiring and updating the location
information. The device should not have to anticipate the required form
of location (i.e. provide everything to everyone). By the same token,
removing location-form negotiation from any given application protocol
and allowing the application platform to do the negotiation directly
with the LIS is a valid way of minimizing application protocol
maintenance and complexity.

Cheers,
Martin

> Sent: Wednesday, 13 September 2006 3:38 AM
> To: Dawson, Martin
> Cc: [email-masked]
> Subject: Re: [Geopriv] coming to terms on location by reference
> 
> I'm not going to argue with the fact that network efficiency
discussions
> are
> That's an interesting point, though my understanding of the
requirement

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Sep 2006 21:10:31 -0400

> failure in implementation as an argument against a mechanism.

I've been using the terms authentication and authorization  
interchangeably, and that has likely caused confusion.  I meant to  
say that the implementation works as intended, and the outcome of an  
authorization policy is that the location dereference is denied.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Sep 2006 20:18:01 -0500

If the purpose of the location request is in support of emergency calls
- In particular, in the i2 architecture, if the LIS denied the provision
of location information despite the VPC authenticating itself as a
function of the emergency services network, then there was an error in
the application of the authorization policy - assuming the authorization
policy in the jurisdiction from which the call is originating is that
emergency services requests are always permitted.

Cheers,

Martin

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, 13 September 2006 11:11 AM
To: Dawson, Martin
Cc: [email-masked]
Subject: Re: [Geopriv] coming to terms on location by reference

I've been using the terms authentication and authorization
interchangeably, and that has likely caused confusion.  I meant to say
that the implementation works as intended, and the outcome of an
authorization policy is that the location dereference is denied.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 12 Sep 2006 21:43:49 -0400

On Sep 12, 2006, at 9:18 PM, Dawson, Martin wrote:

> If the purpose of the location request is in support of emergency  
> calls - In particular, in the i2 architecture, if the LIS denied  
> the provision of location information despite the VPC  
> authenticating itself as a function of the emergency services  
> network, then there was an error in the application of the  
> authorization policy – assuming the authorization policy in the  
> jurisdiction from which the call is originating is that emergency  
> services requests are always permitted.
Martin,

Compatibility with NENA i2 should not be taken as a foregone  
conclusion.  If there is a desire for compatibility with NENA i2,  
then that is a point of discussion for this working group and this  
requirement should be made explicit.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 12 Sep 2006 21:46:33 -0400

Okay, so what I really care about is interoperability.

I don't think there is any real reason to have more than one protocol that
takes a URL and returns a PIDF, but maybe you could supply one.  Presence is
already defined, and meets the geopriv requirements.  No more work; a good
thing.  A LIS, if that is all that it is, can supply a bare PIDF (with an
unlinked identity if you wish) and the PIDF-LO elements.  That's pretty
minimal mechanism, albeit not the most minimal you could imagine. 

If for some reason, there actually is a reason to have another URL in, PIDF
out, then what I want is all LIS' to implement the SIP Subscribe/Notify, and
then they can also implement any other protocols they want.  Clients need
only implement SIP Subscribe/Notify to be compatible with any LIS.  What
would be fatal is if we have an expanding list of protocols implementable by
either end, and interoperability was a roll of the dice.  

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Tuesday, September 12, 2006 6:15 PM
> To: Brian Rosen; Andrew Newton; [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Sep 2006 20:59:24 -0500

Brian,

I like to think that this is more than just something about SIP.
I see webservices and the like wanting location and references being a
good way to enable that.

If I had to bet on whether more devices and services are http enabled
than SIP enabled I know where I would put my money. I would like to see
the lowest common denominator as HTTP rather than SIP, as I don't see
SIP as being the long term widest user of this functionality.

Cheers
James

> Sent: Wednesday, 13 September 2006 11:47 AM
> To: Dawson, Martin; 'Andrew Newton'; [email-masked]
> takes a URL and returns a PIDF, but maybe you could supply one.
Presence
> is
> out, then what I want is all LIS' to implement the SIP
Subscribe/Notify,
> and
> would be fatal is if we have an expanding list of protocols
implementable
> by
> > > In my opinion, location by reference was defined when we accepted
the
> > > notion
> > > SUBSCRIBE operation on a presence URL, you may get back a NOTIFY
with
> > > reference instead of a value, short of doing the dereference
itself,
> > it
> > > server argument, and it pretty much rings true, especially if
there is
> > > more
> > > The real question in my mind is, is presence SUFFICIENT?  Do we
need
> > any
> > > > Additionally, this working group has discussed
location-by-reference
> > > with
> > > > regard to its component uses in location configuration
protocols,
> > > location
> > > > not given their opinions.  But it is now time for us to
determine
> > how we
> > > > should move forward on location-by-reference, either accepting
it as
> > > > 1) Location-by-reference offers better efficiency where location
of
> > a
> > > > target
> > > > is not determined by the target and when the target wishes to
convey
> > its
> > > > location.  It is more efficient because the target does not have
to
> > > first
> > > > example, a referent host may require authentication that could
cause
> > the
------------------------------------------------------------------------
> --
> > ----------------------
------------------------------------------------------------------------
> --
> > ----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Sep 2006 21:02:01 -0500

I'm not citing i2 as a requirement - but, by way of example, I am
pointing out that emergency services in a jurisdiction that permits
emergency requests for location at all times would actually be
encountering an error in authorization if the LIS subsequently denied
access via the reference.

In a jurisdiction that does not place emergency services agents in that
privileged position, as you say, then the de-reference may not be
permitted. However that is a consequence of the jurisdiction's policy.
None of the numerous arguments in favor of location reference are
intended to suggest it be exclusive. For example, I would never argue
that location by value should not be supported. I believe we need to
give users the options that are applicable to their deployments. We most
certainly should not be attempting to engineer every possible solution
based on our own pre-conceptions.

Cheers,
Martin

> Sent: Wednesday, 13 September 2006 11:44 AM
> To: Dawson, Martin
> Cc: [email-masked]
> > authorization policy - assuming the authorization policy in the

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Sep 2006 21:15:52 -0500

I was waiting for the "I just want to minimize complexity in the sincere
interests of interoperability" response. However, location by value and
location by reference are two quite distinct and valid approaches to
getting location information to the end-using application. It is valid
to support both mechanisms in a communication protocol just as it is
valid to support both mechanisms for transferring data within a
programming language. Value and reference are not the same thing.

The point of the discussion is about whether location by reference has
value.

You've repeatedly said that you only want SIP as the type of the
reference. Which really means you actually only want SIP to be able to
be used as the location "configuration" protocol supported from the LIS
- for whatever reason. However, that's a quite separate discussion. I
certainly disagree and I believe the "Layer 7" protocol WG are the ones
who are kicking the question around of what makes a good solution for
this. I like HELD; it's designed specifically for the purpose of getting
location and has semantics designed to meet requirements for delivering
location that have been documented by a user community that has a
genuine need for the given requirements. I believe HELD also meets the
requirements of a "using protocol". These are my views - and it's still
a different topic. I certainly agree that LIS can implement any protocol
they like including SIP as an option. I don't agree that SIP has some
special status in this regard. Time will tell which protocol is most
successful. 

Cheers,
Martin

Presence
Subscribe/Notify,
implementable
the
with
itself,
there is
need
location-by-reference
protocols,
determine
it as
of
convey
to
cause

---

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 08:36:41 -0400

On Sep 12, 2006, at 10:15 PM, Dawson, Martin wrote:

> this.

Just for clarification: the L7-LCP design team is not another working  
group but is a design team of the GEOPRIV working group.  This allows  
them to operate as an IETF function, but their work will have to be  
approved by the GEOPRIV working group.  They were tasked with  
generating requirements for a Layer 7 Location Configuration Protocol  
but not the development of such a protocol.

Thanks to the work of the L7-LCP design team, we all have a better  
understanding of the problem.  One of the take-aways from their work  
is that the L7-LCP, or any LCP, does not have to be the same protocol  
used for conveyance (what we call a "using protocol").  There have  
been three individual protocol proposals for an L7-LCP, and none use  
SIP.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 08:46:32 -0400

>Thanks to the work of the L7-LCP design team, we all have a better
understanding 
>of the problem. One of the take-aways from their work is that the L7-LCP,
or any LCP, 
>does not have to be the same protocol used for conveyance (what we call a
"using protocol"). 
>There have been three individual protocol proposals for an L7-LCP, and none
use SIP.

Right, and the dereference protocol does not have to be the same as the LCP.
The L7-LCP design team is not working on a dereference protocol.

Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 15:04:17 +0200

Hi Andy,

Andrew Newton schrieb:
>> also do not allowed location-per-value inserted by a SIP proxy) then 
>> it seems that we have to get rid of this scenario as well.
> 
> I started a separate thread 2 weeks ago about proxy insertion of 
> location by value, which is not the same thing as location by 
> reference. 

I forgot about this mail.

  I purposefully have tried to separate these two items as
> they are separable and each can exist without the other.  So far, nobody 
> has objected to proxy insertion of location by value.

That's true except that Jon does not seem to have read it.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 15:05:08 +0200

Hi all,

~snip~

> Instead, the observation was that the authentication would work and 
> would deny location dereference thus causing the failure of emergency 
> call routing.
>

We need to discuss who the entity is that creates the reference. Let us 
call this entity 'Reference Creator'.

There are two possible cases:

a) The Target has a relationship with the Reference Creator
b) The Target does not have a relationship with the Reference Creator

By 'relationship' I mean that the Reference Creator knows the identity 
of the Target and its privacy policies.

Additionally, there is the question about the where the Reference 
Creator gets the location from. There are two issues to consider:

1) The Reference Creator knows it (e.g., since the Reference Creator is 
located in the access network)
2) The Reference Creator was told the Target's location information by 
the Target
3) The Reference Creator was told the Target's location information by 
an entity other than the target (e.g., RADIUS-GEOPRIV providing location 
info to the user's home network if the same entity is used for

These scenarios have an impact on
* the ability to put something meaningful into a PIDF-LO
* the security properties when it comes to the ability to utilize 
authorization policies regarding the selective disclosure of location 
information to Location Recipients in order to address the retargeting 
problem.

Here are a few examples:

Consider a DSL network where a user also uses their presence service in 
addition to Internet connectivity. This would be (a) + (1). In this case 
  a call could easily be routed via the SIP proxy in the access network 
that attaches a location reference and the user might also have some 
policy uploaded that control access.

Another example is (a) + (2) whereby the Target uses a SIP Publish to 
upload location information obtained from the access network (e.g., 
using DHCP). The presence server can be located anywhere. The call is 
routed through the user's preferred proxy server that somehow has access 
to the previously obtained location & privacy info. The authorization 
policies can also be uploaded by the end host.

The above-mentioned scenarios obviously work fine.

The problems start with scenarios related to (b) where you have a
Target does not have a relationship with the Reference Creator.

The above-mentioned issues provide some hints how the authorization 
could work at the Reference Creator when the reference is resolved to a 
location object. These cases do not provide help for emergency services 
as we already discussed in the Geopriv-L7 design team.

Is an analysis along these lines helpful or only confusing?
What would be a better way to analyze the scenarios in more detail?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 15:08:27 +0200

Hi Martin,

this was aspect was discussed in the Geopriv-L7 design team.
It was seen as a problem to setup the infrastructure in order to provide 
the authorization policies and the key exchange infrastructure to allow 
Location Recipients (e.g., PSAPs) to resolve the reference to a location 
objects from the LIS.

Ciao
Hannes

Dawson, Martin schrieb:
> the application of the authorization policy – assuming the authorization 
> *From:* Andrew Newton [mailto:[email-masked]]
> *Sent:* Wednesday, 13 September 2006 11:11 AM
> *To:* Dawson, Martin
> *Cc:* [email-masked]
> *Subject:* Re: [Geopriv] coming to terms on location by reference
> 
>  
> 
>  
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 15:15:39 +0200

Hi Brian,

Brian Rosen schrieb:
> thing.

as you can see from my separate mail with the analysis of the different 
scenarios I strongly believe that only for some scenarios you have a 
match with the presence architecture but NOT for all scenarios.

Henning hinted to the performance different between different 
referencing protocols.

   A LIS, if that is all that it is, can supply a bare PIDF (with an
> either end, and interoperability was a roll of the dice.  

In the architecture discussed in the Geopriv-L7 DT we have the LIS in 
the access network. If we focus on SIP based protocol only why do we 
need a protocol that provides the reference to the end host when we 
could just route the calls via the SIP proxy in the access network (=the 
NGN architecture).

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 09:26:46 -0400

To amplify: The fundamental problem is that, in general, a LIS can't  
know all the legitimate recipients of location information and the  
PSAPs (and other associated entities, such as first responders) do  
not know all or even most of the LIS, as these can be operated by  
thousands of entities within a particular jurisdiction. Both sets are  
fairly dynamic, sometimes on short time scales ('mutual aid').

In addition, the LIS does not generally know whether the target is in  
a state of emergency, and how long this state lasts. Also, just  
because a target is in such a state does not mean that the target  
would appreciate being monitored by just anybody during that state,  
including possibly bad guys that are the cause of the emergency.

In such situations, establishing authentication and authorization  
policies is challenging, particularly if you want to avoid false  
negatives and want to avoid giving a blanket license to every  
volunteer fire fighter to track their neighbors 24x7.

If LIS-chosen nonces, tokens and such are used, UAs need to be  
reliably aware of them and one needs to be sure that they don't  
occasionally expire at inopportune moments, such as in the middle of  
an emergency call.

"Challenging" doesn't mean impossible, but it's one of the problems  
where one can't just tell implementors to have fun and good luck.  
One's perception of challenge often depends on assumptions of how  
easy it is to coordinate large numbers of independent entities and  
how easy it is to set up new infrastructure. What seems trivial to  
one person or in one jurisdiction, may seem an impossible political  
or economic deployment nightmare to somebody else in another  
jurisdiction.

Capturing these issues would probably be helpful, if only to avoid  
repeating the same discussion over and over.

On Sep 13, 2006, at 9:08 AM, Hannes Tschofenig wrote:

> It was seen as a problem to setup the infrastructure in order to  
> provide the authorization policies and the key exchange  
> infrastructure to allow Location Recipients (e.g., PSAPs) to  
> resolve the reference to a location objects from the LIS.
>
> Ciao
> Hannes
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 09:37:36 -0400

Hannes

I cannot follow the latter part of this discussion, when the reference
creator does not have a relationship with the target.

First it occurs to me that you may wish to discriminate the case where there
is a relationship, but there is a lack of identity transfer between domains.
The example is the DSL network that does not have any actual presence
service.  The DSL network has a relationship with the target; the target is
its subscriber.

There could be other cases where there really is no relationship.  Consider
applications in which there are mechanisms tracking targets where the
targets are completely unaware they are being tracked.  There is then no
relationship.  I'm not sure we really care a lot about such cases, but they
exist.

I would think in the former case that:
a) The access network MUST obtain policy from its subscriber in order to
meet Geopriv requirements.
b) The location provided would probably NOT have any identity information
c) I do think that we cannot allow an authentication failure between the
watcher and the Location Server in the emergency case, but I point out that
if you do not have identity in the location, some privacy issues are less of
a concern than if you do.  
d) Agree that security of reference = security of value.  
e) Point out that the Location Server can run a "presence service" which
provides a PIDF with an anonymous identity and location, and nothing else in
exchange for a URI it constructs.  That is a very simple way for an access
network to provide a location by reference.  There is no identity transfer
here; there is no identity in the location, or the URI.  Except for the
emergency case, the server can still authenticate the watcher without
revealing anything related to the target, and the watcher doesn't need any
identity of the target to watch; all he needs is the URL.  If the URL
contains no identity information, which in this case it should, then I think
everything is okay except the "how do you tell an emergency case" problem.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2006 9:05 AM
> To: Andrew Newton
> Cc: [email-masked]; Dawson, Martin
> Subject: Authentication/Authorization Issues: Re: [Geopriv] coming to
> termson location by reference
> 
> Hi all,
> 
> ~snip~
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 15:39:14 +0200

Nice summary, Henning.

In the design team I thought we concluded that the usage of policy has a 
number of disadvantages/limitations. Maybe our analysis was not good 
enough but I haven't seen a better one. Every entity that possesses the 
URI is allowed to retrieve it. There seems to be the desire to put the 
existing presence authorization work (and a similar mechanism for HTTP) 
into the picture for some reason.

Ciao
Hannes

Henning Schulzrinne schrieb:
> know all the legitimate recipients of location information and the PSAPs 
> (and other associated entities, such as first responders) do not know 
> all or even most of the LIS, as these can be operated by thousands of 
> entities within a particular jurisdiction. Both sets are fairly dynamic, 
> sometimes on short time scales ('mutual aid').
> 
> In addition, the LIS does not generally know whether the target is in a 
> state of emergency, and how long this state lasts. Also, just because a 
> target is in such a state does not mean that the target would appreciate 
> being monitored by just anybody during that state, including possibly 
> bad guys that are the cause of the emergency.
> 
> negatives and want to avoid giving a blanket license to every volunteer 
> fire fighter to track their neighbors 24x7.
> 
> If LIS-chosen nonces, tokens and such are used, UAs need to be reliably 
> aware of them and one needs to be sure that they don't occasionally 
> expire at inopportune moments, such as in the middle of an emergency call.
> 
> where one can't just tell implementors to have fun and good luck. One's 
> perception of challenge often depends on assumptions of how easy it is 
> to coordinate large numbers of independent entities and how easy it is 
> to set up new infrastructure. What seems trivial to one person or in one 
> jurisdiction, may seem an impossible political or economic deployment 
> nightmare to somebody else in another jurisdiction.
> 
>> provide the authorization policies and the key exchange infrastructure 
>> to allow Location Recipients (e.g., PSAPs) to resolve the reference to 
>> a location objects from the LIS.
>>
>> Ciao
>> Hannes
>>
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 09:56:07 -0400

> policies can also be uploaded by the end host.

Isn't there a third set of scenarios, all established by the access network 
handing out location references instead of location values?

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 16:01:43 +0200

Hi Brian,

thanks for responding to this subject.

> service.  The DSL network has a relationship with the target; the target is

One might further detail the scenarios. I was just wondering whether the 
Reference Creator has the information to build a PIDF-LO. If there is a 
relationship between the Reference Creator and the Target then things 
are much simpler. There are, however, some applicability statements / 
assumptions around this.

To address the case where there is no relationship between the Reference 
Creator and the Target HELD has taken the approach to upload identity 
and privacy policy information to the LIS.

> relationship.  I'm not sure we really care a lot about such cases, but they

I do not consider such a scenario.

> b) The location provided would probably NOT have any identity information

entity element in the PIDF-LO = empty.

> a concern than if you do.  

Do you think that the access network needs to have possession of the 
authorization policies ? (as, for example, provided by HELD)

> d) Agree that security of reference = security of value.  
I thought that we agreed to this already.

> everything is okay except the "how do you tell an emergency case" problem.
I am not sure that this works. How do you make the differentiation 
between a PSAP and an arbitrary Location Recipient when they ask for 
location at the LIS/presence server without authenticating them first?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 16:07:06 +0200

Hi Andy,

Andrew Newton schrieb:
>> routed through the user's preferred proxy server that somehow has 
>> access to the previously obtained location & privacy info. The 
>> authorization policies can also be uploaded by the end host.
> 
> Isn't there a third set of scenarios, all established by the access 
> network handing out location references instead of location values?
> 

In many cases (with roaming and mobility) this would be something like 
(b) and (1).

In some cases, such as the DSL networks, there is the possibility to 
have (a) and (1).

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 10:20:30 -0400

> are much simpler. There are, however, some applicability statements /
It can build a PIDF-LO.  The question is what identity is provided in the
PIDF.

> and privacy policy information to the LIS.
I think it's essential to have the target control the policy.  I think the
access network creating an identity that is meaningful to anyone else is
problematic and not helpful.

...snip...
> entity element in the PIDF-LO = empty.
Well, at least anonymous

...snip....
> authorization policies ? (as, for example, provided by HELD)
Yes, I think it does 

...snip...
> location at the LIS/presence server without authenticating them first?
I don't really know how to do this in a way that a protocol can implement.
I think you can do it in a way that a lawsuit would work.

Let me point out that if you take the purpose of the location reference to
get location AND NOTHING ELSE, then a PIDF with the -LO and no/anonymous
identity serves you well.  If you want an identity, then I think you really
do have presence, and you should use it, and not create something that is
identity+location, but not presence.

Basically, since I don't see how anyone will link an access network's notion
of identity with any other identity (say your AoR for a phone or IM
service), then I don't think the access network identity is useful for
anything outside its domain.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Sep 2006 09:56:20 -0500

But there are clear advantages to the LIS if they are the same protocol.

> Sent: Wednesday, 13 September 2006 10:47 PM
> To: 'Andrew Newton'; Dawson, Martin
> Cc: 'Geopriv WG'
> >There have been three individual protocol proposals for an L7-LCP,
and
> none
> use SIP.
> 
> Right, and the dereference protocol does not have to be the same as
the
> LCP.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 10:01:05 -0500

Henning,

I don't see an issue for this in a jurisdiction where the emergency
services authority does have the authorization to obtain location at any
time. The way it is managed in those jurisdictions is that there are a
very limited number of entities that can make this query and they are
provided with a certificate from a jurisdiction-based certificate
authority. Note that I assume a jurisdiction typically equals a country
in this instance though it can be anything.

In jurisdictions that don't provide emergency services with this right,
then the client device may provide explicit indication of rights in its
request for the reference. They may indicate a generic emergency service
provider identity as well as anyone else. They may provide a URL to a
privacy policy controller (ref OMA). They may provide the identity of
only a preferred presence service - meaning all location requests must
be proxied through the presence service and, following a reference
exchange with the presence server, the client then provides the presence
service reference in any application session rather than the direct LIS
reference. These are all options that a variously scalable depending on
the deployment context. They are all valid options and, for example,
allow client deployments without assuming an entire presence
architecture is tied to the ability of users to take advantage of
location from an access network.

Finally, there is still always the option of only using
location-by-value for those jurisdictions where the emergency service
operator is not considered to have any right of autonomous location
update. I don't know if such a jurisdiction exists (that explicitly
forbids emergency services this ability) but the option should be
supported.

When it comes to the LIS, and using Hannes' terminology - I assume that
the LIS is operated by the access network (which is best placed to make
a location determination) and that, ultimately, the LIS will be the
function which is queried when de-referencing occurs (for the same
reason). That is, the LIS is the (root) reference generator. It has a
relationship with the target because the target represents an anonymous
device using the access serviced by that access. The relationship is
transitory, so there is no consideration of a static "user profile" in
the LIS related to the target device. Policy needs to be established in
the context of the transitory relationship between the target and the
LIS. It makes sense to me that the device uses the same protocol to
request a reference as it does to request a location value - with the
appropriate request qualifiers - and the same protocol to indicate
policy to the LIS.

The device applies its own policy to how the reference is subsequently
handled including, as above, passing it directly to using applications,
or requesting a reference exchange with a presence server.

The form of the reference ultimately provided to the application and the
protocol it uses to de-reference it can vary (yes, Brian, it would be
loverrly if there was just one form but different application domains
and imperatives mean that users should be allowed to select what works
for them). Regardless, the protocol used to request the (root) reference
from the LIS needs to permit the device to establish the policy
associated with that reference. The LIS must perform the necessary
authentication and authorization associated with the policy - with any
exceptions associated with jurisdictional policy duly included.

Cheers,
Martin

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, 13 September 2006 11:27 PM
> To: Hannes Tschofenig
> Cc: GEOPRIV

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 10:17:19 -0500

I think I agree with everything Brian has said here.

The fundamental point being that the LIS has a transitory relationship
with the device in the access network - it is not concerned with the
static identity of the device user.

PIDF-LO is supported by the LIS for the provision of location
information because (a) it's good reuse of the existing specification
and (b) it is complementary to the presence architecture should the user
wish to provide the PIDF-LO to it's presence server it comes pre-baked.
It is not used because the LIS is concerned with the identity the device
may have with a presence service. In fact a LIS is a
device-transient-presence service that uses its own unique,
user-independent, and anonymous identity associated with that device.

Cheers,
Martin

> Sent: Thursday, 14 September 2006 12:21 AM
> To: 'Hannes Tschofenig'
> Cc: 'Andrew Newton'; [email-masked]; Dawson, Martin
> Subject: RE: Authentication/Authorization Issues: Re: [Geopriv] coming
to
> > > a) The access network MUST obtain policy from its subscriber in
order
> > > contains no identity information, which in this case it should,
then I
> > think

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 13 Sep 2006 17:21:25 +0200

> PIDF-LO to every application.

What about combining by-value with by-reference? Then the receiver:
1. gets a reference to obtain location updates and the preferred 
location format, and
2. if 1. fails, there is still a location-by-value

Of course this adds complexity to the client but IMO there is a benefit.

regards
Klaus

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 13 Sep 2006 11:33:53 -0400

> The DSL network has a relationship with the target; 
> the target is its subscriber.

I thought the customer premises network used by the target is operated
by a subscriber of the ISP, and the ISP is the subscriber of the access
network provider. At least, that's how it works in our network. I do
know of some cases where the access provider and ISP are the same, but
I'd like to see a little more care in discussing who has responsibility
for what, and who has a relationship with whom. In some HELD
architectural discussions (such as in NENA), we had the target querying
the ISP LIS, who in turn queried the access provider LIS. I'm curious as
to what sort of architecture this discussion is leading towards.

In the common wholesaling scenario, the access provider frequently does
not have any sort of business relationship, at all, with the target.
Often, either contractually or through regulatory rules, the access
provider isn't supposed to provide any services (other than a physical
pipe) directly to devices on the premises network. This is the ISP's
subscriber, and NOT the access provider's. I'm curious how LIS discovery
would work, if we were expecting the target to discover an access
provider LIS, instead of an ISP LIS, since the ISP operates the DNS
servers, and is responsible for all IP layer routing (including ports or
any redirection rules).

Also, the ISP often doesn't know whether or not it has a business
relationship with the target. The ISP knows the account being used to
access the ISP, but doesn't know what relationship the target has to
that account. If a cafe is operating a simple free hotspot, the cafe is
the ISP's subscriber, and any target devices may or may not be customers
of that cafe. The ISP doesn't know the target. It doesn't know the
target's identity (other than its IP address -- or is that what you mean
by identity?) or its privacy policies. Also, I'm the ISP's subscriber in
my household, but the ISP has no idea whether a target device is being
operated by me or someone else. All the ISP knows is the IP address that
it uses to communicate with that target. Multiple targets can use the
same IP address, and my reading of things is that not all targets (using
the same IP address) will have the same privacy policies. Or are we now
moving privacy policy away from belonging to a target, to belonging to
an IP address?

Because of this, I think it's a really bad idea to state that all LISs
MUST also be presence servers and support privacy policies. I think it's
a good idea for a protocol to support transmission of privacy policy,
but don't believe it should be a required function of a LIS.
Barbara

Barbara

*****

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. GA622

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 10:50:29 -0500

All,

Is there any general interest for an update to RFC 3693 (and please notice 
that I said "update" not "obsolete")?

For starters, I think we have evolved different terminology than that of RFC 
3693, in some cases opting for newer terms that are clearer than what 3693 
defines.  For instance, we talk about location configuration protocols and 
not "sighting" protocols.  Those two things are different.  For "using 
protocol", we usually mean "inter-domain conveyance," etc....

Comments?

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 10:50:29 -0500

Yes, I think that's a perfectly reasonable option. While the thread
started as a general discussion about "location by reference", this
sub-thread is focused on servicing the emergency service scenario. I
think the implementers of specific deployment scenarios should always
have the option of having both forms conveyed - and that includes the
emergency VoIP service scenario.

Cheers,
Martin

> From: Klaus Darilion [mailto:[email-masked]]
> Sent: Thursday, 14 September 2006 1:21 AM
> To: Dawson, Martin
> Cc: Andrew Newton; [email-masked]

964a31702fa68f1ff0e955
Cc: [email-masked], Andrew Newton <[email-masked]>
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Yes, I think that's a perfectly reasonable option. While the thread
started as a general discussion about "location by reference", this
sub-thread is focused on servicing the emergency service scenario. I
think the implementers of specific deployment scenarios should always
have the option of having both forms conveyed - and that includes the
emergency VoIP service scenario.

Cheers,
Martin

> From: Klaus Darilion [mailto:[email-masked]]
> Sent: Thursday, 14 September 2006 1:21 AM
> To: Dawson, Martin
> Cc: Andrew Newton; [email-masked]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Sep 2006 12:18:02 -0400

Andy,

One thing I continue to look for when L by R solutions are discussed is the
underlying requirements.  In other words, what problem is L by R solving
that can't be solved by existing mechanisms.

1) The only requirement that I've been able to glean from the multiple years
of this discussion is the business requirement of not letting the target
know the location.  Notwithstanding personal opinion on this, this
requirement obviously cannot be accomplished by current mechanisms. 

2) Any attempt to cite bandwidth efficiency as a requirement doesn't
normally motivate Internet engineers, lack of bandwidth isn't normally
associated with Internet devices.

3) The citation of the NENA i2 architecture failing for wireless devices
without a L by R mechanism needs more clarification.
	a) The i2 specification is targeted at residential WIRELINE
replacement by VoIP devices normally not thought of as mobile.
	b) The i2 architecture defines a 'gateway' between the VoIP world
and the legacy.
	c) I see no reason why any mechanism to support wireless location
updates won't work for i2 (no need for a specific mechanism).

-Marc-

> (http://www.ecotroph.net/~anewton/hypermail/geopriv/0607/2717.
> html), we have not truly come to consensus on location by 
> reference within this working group.  The GEOPRIV working 
> group has been presented with many individual submissions for 
> both architectural considerations and concrete solutions. 
> location-by-reference with regard to its component uses in 
> location configuration protocols, location dereference 
> protocols, and location conveyance protocols. As a working 
> stands, there are many who feel it is valuable, many who feel 
> it is not, and many who have not given their opinions.  But 
> it is now time for us to determine how we should move forward 
> on location-by-reference, either accepting it as a whole, 
> accepting it in limited form, or rejecting it entirely.
> 
> 1) Location-by-reference offers better efficiency where 
> location of a target is not determined by the target and when 
> the target wishes to convey its location.  It is more 
> efficient because the target does not have to first retrieve 
> the location in order to convey it.
> 
> 2) Location measurement and determination (sighting) of a 
> target by another element is of limited scope as 
> self-determination methods such as GPS may offer greater accuracy.
> 
> consequences.  For example, a referent host may require 
> authentication that could cause the failure of emergency call 
> routing.  Therefore, location-by-reference may not 
> To further this discussion so that we may come to resolution 
> on this topic, I welcome comments regarding the above as well 
> as further observations.
> 
> -andy
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 11:40:36 -0500

This piece of misinformation about i2 continues to be promulgated. The
i2 *working group* was tasked with defining a solution for fixed
subscriber access and was encouraged to find a solution supporting
wireless access as well. The i2 *architecture* was based off the
cellular mobile interfaces and *most definitely* supports mobile
devices. That's one of the main reasons that the V3 interface exists.

As far as I know it is primarily the detractors of location by reference
who continue to raise the "business model benefit" and it's done so as
some kind of anti-benefit statement presumably to discredit the entire
concept by association. Objections to this particular use
location-by-reference are apparently based on an ideological criterion
that has no place in the engineering of a protocol that provides useful
functions to those that want to implement them.

I cited a quite extensive list of the benefits location-by-reference
previously that goes beyond the two you have gleaned. Would you like
them re-listed?

Cheers,
Martin

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Thursday, 14 September 2006 2:18 AM
> One thing I continue to look for when L by R solutions are discussed
is

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 13:53:06 -0400

i2, as currently defined, does not support mobility, in that, for example it
does not define a mechanism by which a VPC can determine that the location
of the caller is mobile, and thus refresh of location when queried by the
PSAP is needed.  It does not specifically prevent mobility, it is silent on
the matter.  The current implementations of i2 would not support mobility,
as I understand them today, but could be extended relatively easily to do
so. 

You are correct that the architecture was envisioned to cover mobility, and
we repeatedly stated that we would try to cover the mobile case in the
architecture.  The current specification has gaps.

I would appreciate your list of benefits.  I quick look in my archive did
not yield a result.  I'm sure you have provided them, I just can't find
them.

I'd also like to understand if you believe we have a requirement to allow
the LIS to control access to location for business purposes.  I agree that
simply stating a negative is not a particularly useful approach unless there
are people advocating the positive.  Do you believe we:
1) Have a requirement that the endpoint NOT get location, while allowing it
to direct a 3rd party to get its location, perhaps by some sort of token?
2) Have a requirement that the LIS control access to location independent of
the target's policy as embodied in the ruleset?

Brian

> Sent: Wednesday, September 13, 2006 12:41 PM
> To: Marc Linsner; Andrew Newton; [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 14:11:06 -0400

> in this instance though it can be anything.
While I believe that, in normal circumstances, this can be made to work
reliably, I don't want to create a situation in which a failure here causes
a call to not get location.

For example, suppose there was a massive (disaster) failure that resulted in
some PSAP not previously considered a backup handling calls.  How would it
get credentials to all access networks?

In emergencies, the unexpected happens.  It's got to fail safe.

> location from an access network.
I think you confuse the basic SIP SUBSCRIBE/NOTIFY with a PIDF and a full
blown presence system.  The basic mechanism is a pretty simple way to get a
location out of a LIS.  

What I object to is an attempt to make the LIS more than it is: a location
server.  I wonder if it would be helpful if we could just consider that
there are pretty bare LIS' (which always gives you location without
identity) and a presence system, which has identity and possibly other
elements besides location.

What I don't see here is a value in a LIS that has target identity (other
than whatever you present to the LIS to get the location: the LCP protocol
identity or a URL for location-by-reference.  I don't see any reason to
RETURN any other identity information, and if you do, then I want all the
presence ruleset provided to control it.   

> forbids emergency services this ability) but the option should be
Please don't confuse location update with location-by-reference.  You can
use location-by-reference for one way to do location update pull.  You can
do that other ways, and you can use presence to do push.

> appropriate request qualifiers - and the same protocol to indicate
Our views differ slightly, but mostly I agree.  I agree that the LIS will
normally be operated by the access network.  I understand the assumption you
are making when you say the LIS is the dereference server.  It may actually
be that the LIS hands the endpoint a reference, which the endpoint gives TO
ITS PRESENCE SERVICE, and subsequently gives a presence URL to any other
entity it wishes to supply location (among other things).  Still, the LIS
would dereference the thing that it gave the endpoint (presence service is a
watcher to the LIS), which is your notion of "root reference generator".  

I'm not sure it's correct to say that the device is anonymous with respect
to the access network; by definition, the device hands the LIS some kind of
identity, which the LIS responds to with LbyV or LbyR, so the device is not
anonymous to the LIS.  The location object the LIS hands out (to the
endpoint or another entity presenting a reference) would be anonymous in my
view.  The target most definitely has policy that MUST be honored by the
LIS, and by any dereferencer (and any other entity the dereferencer gives
the location to, if the target's policy permits retransmission).  I don't
understand the word "transitory" in this context.  The relationship between
the target and the LIS is not transitory.

I agree that the configuration protocol (endpoint to LIS) should be the same
whether it's LbyR or LbyV.  It does not follow that the dereference protocol
(between the dereferencer and the LIS) should be the same.  If the LCP had a
policy upload function, I would consider that a good thing.  I'm not sure
it's a requirement that it be the same protocol, but I think it's very
desirable.

> or requesting a reference exchange with a presence server.
Well, subject to the target's ruleset, right?

> exceptions associated with jurisdictional policy duly included.
Of course we seem to disagree about the requirement of a LIS to have one
mandatory to implement dereferencing protocol.  Agree that the LIS must
honor the policy of the target, and must supply the policy with the object.
Agree that jurisdictional policy might override.

Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Sep 2006 14:01:04 -0400

Martin, 

> i2 *working group* was tasked with defining a solution for 
> fixed subscriber access and was encouraged to find a solution 
> supporting wireless access as well. The i2 *architecture* was 
> based off the cellular mobile interfaces and *most 
> definitely* supports mobile devices. That's one of the main 
> reasons that the V3 interface exists.

I view the i2 V3 interface in the same category as L by R in sip conveyance
and L by R in the L7 LCP design team work.  None of these answer the basic
question of what are we trying to do that can't be done with existing
mechanism(s), in other words, the requirements.

> 
> As far as I know it is primarily the detractors of location 
> by reference who continue to raise the "business model 
> benefit" and it's done so as some kind of anti-benefit 
> statement presumably to discredit the entire concept by 
> association. Objections to this particular use 
> location-by-reference are apparently based on an ideological 
> criterion that has no place in the engineering of a protocol 
> that provides useful functions to those that want to implement them.

My mention of the business model was actually demonstrating a positive for
the L by R justification.  We can take it off the table if you wish.

> 
> I cited a quite extensive list of the benefits 
> location-by-reference previously that goes beyond the two you 
> have gleaned. Would you like them re-listed?

Not necessary to repeat.  I read this prior to drawing my conclusions below.
I can comment on each point in the mentioned email if you wish.

-Marc-

> > 1) The only requirement that I've been able to glean from 
> the multiple 
> > years of this discussion is the business requirement of not letting 
> > the
> target
> reference 
> > > within this working group.  The GEOPRIV working group has been 
> > > presented with many individual submissions for both architectural 
> > > considerations and concrete solutions.
> > > with regard to its component uses in location configuration 
> > > protocols, location dereference protocols, and location 
> conveyance 
> > > protocols. As a working group, we are much further along in our 
> > > understanding of location-by-reference than we were just 
> 1 year ago. 
> > > And as it stands, there are many who feel it is valuable, 
> many who 
> > > feel it is not, and many who have not given their 
> opinions.  But it 
> > > is now time for us to determine how we should move forward on 
> > > location-by-reference, either accepting it as a whole, 
> accepting it 
> > > in limited form, or rejecting it entirely.
> > >
> > > on this
> location of 
> > > a target is not determined by the target and when the 
> target wishes 
> > > to convey its location.  It is more efficient because the target 
> > > does not have to first retrieve the location in order to 
> convey it.
> > >
> target by 
> > > another element is of limited scope as self-determination methods 
> > > such as GPS may offer greater accuracy.
> > >
> > > routing.  Therefore, location-by-reference may not appropriate or 
> > > could even be harmful for certain use cases.
> > >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 15:02:50 -0400

> a call to not get location.

There's also a more subtle issue. Since the LIS doesn't know when 
there's an emergency, such a certificate essentially gives every PSAP, 
i.e., every police department, the immediate and continuous ability to 
obtain the movement records of citizens anywhere in the country, without 
the (modest) check of having to present a warrant to the carrier and a 
fairly extensive approval process which is reasonably heavy-weight.

At least some people might find such a capability a bit scary.

Even if you don't worry about the being snooped on officially, it 
significantly lowers the bar for local mischief by rogue or bored PSAP 
call takers or first responders. There have been enough stories about 
surveillance cameras being used for "entertainment" purposes that I'd 
rather not give random employees in two-person PSAPs run on a kitchen 
table (which roughly describes the one in my town) the capability to do 
that.

In addition, there are likely to be various non-governmental entities 
that might handle emergency calls, such as the equivalent of OnStar or 
VSP-operated default call centers. They would presumably also need the 
ability to query for location information. Now, I'm giving such 
capability to minimum-wage call center employees that used to sell 
replacement windows the week before.

There's also a more unlikely failure scenario: Unless there's some kind 
of certification body and capability-based certs, you end up with 
thousands to tens of thousands of entities sharing the same private key. 
This is not a comforting thought.

Even with capability-based certs, this mechanism has a particularly 
nasty single-compromise failure. If a bad actor manages to obtain one 
such certificate (by pretexting, say, to use the word of the week), that 
bad actor can get the location information of the whole citizenry of the 
whole country, not just the call records of a few board members.

In short, some protocol capabilities are best left out since they are 
just too dangerous when they *succeed*. (There are other ways to deal 
with L-by-R authorization, but I find the certificate one particularly 
objectionable and dangerous. I'm very troubled that proponents of L-by-R 
advocate them.)

> it's a requirement that it be the same protocol, but I think it's very

For the case of SIMPLE, XCAP is the to-be standardized policy upload 
protocol. It seems unlikely that this would be appropriate for the other 
functions.

Henning

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 13 Sep 2006 16:08:06 -0400

> Clients need only implement SIP Subscribe/Notify to be compatible with
any 
> LIS. 

Brian,
I'm not very up-to-speed on this SIP SUBSCRIBE/NOTIFY stuff, and was
hoping you could help explain something. I'm trying to understand what
would be needed on a device that either doesn't have a fully functional
SIP client (that may or may not be configured to make calls), or that
doesn't know it has such a client.

For example, I think I'd like for a PC to do location determination
shortly after starting. Always. My PC may or may not have a SIP client
application on it. Right now, I don't subscribe to any VoIP service, so
I don't have a client on it. And let's say that the PC is given a
location reference, and wants to go ahead and de-reference, so it has
what it needs for a LoST look-up.

How much of a SIP stack do I need for a SUBSCRIBE/NOTIFY? Is there a
suggestion as to how the PC identifies itself in the SIP message (I'm
assuming the PC doesn't have an account with a voice service provider,
or such, since that wouldn't be good to require of it)? I'm not too
clear on how point-to-point SIP works, but where does the PC go to look
up the SIP urn that it sends the SUBSCRIBE to, so it has an IP address
for routing? Does this need to be hard-coded into the operating system?
Or is any look-up required?

I really am curious, really don't know, and I'm not just pretending to
be dumb...
Barbara

*****

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. GA624

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 22:29:48 +0200

Hi Barbara

to simplify the description of the scenarios we indeed assumed that the 
access network consists of link layer provider and IP provider. We just 
assumed that these are the same for sake of simplicity. But you are 
right that we would have to provide a more detailed description, for 
example, in a document.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 22:29:52 +0200

Hi Brian,

> It can build a PIDF-LO.  The question is what identity is provided in the

True. What information is placed into the PIDF part and what information 
is placed into PIDF-LO rule sets.

> I think it's essential to have the target control the policy.

Then, the question remains: How.

   I think the
> problematic and not helpful.

I have several times stated the question whether the identity field has 
some semantic associated. Nobody ever responded. I don't know whether 
you can just put garbage in there.

>> entity element in the PIDF-LO = empty.

Fine with me.

>> authorization policies ? (as, for example, provided by HELD)

Ok.

>>> everything is ok except the "how do you tell an emergency case"
>> problem.

Ok.

> anything outside its domain.

I have no idea either how this would work. At least it does not work in 
almost all of the scenarios.

Ciao
Hannes

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Sep 2006 16:31:24 -0400

Barbara,

Not trying to steal Brian's thunder, but a way to think about your
questions: LIS discovery and end host (target) identifier are problems no
matter the resolution protocol.  And any dereferencing protocol would
require the appropriate application residing on the host, using SIP would
benefit from work already done and the chance that a voip application on the
same host could/would share code.

pres:[email-masked]

I realize I'm talking in the solution space, and still do believe we need to
document the requirements per my other rant(s).

-Marc- 

> From: Stark, Barbara [mailto:[email-masked]] 
> Sent: Wednesday, September 13, 2006 4:08 PM
> To: Brian Rosen; Dawson, Martin; Andrew Newton; [email-masked]
> I'm not very up-to-speed on this SIP SUBSCRIBE/NOTIFY stuff, 
> and was hoping you could help explain something. I'm trying 
> to understand what would be needed on a device that either 
> doesn't have a fully functional SIP client (that may or may 
> not be configured to make calls), or that doesn't know it has 
> such a client.
> 
> For example, I think I'd like for a PC to do location 
> determination shortly after starting. Always. My PC may or 
> may not have a SIP client application on it. Right now, I 
> don't subscribe to any VoIP service, so I don't have a client 
> on it. And let's say that the PC is given a location 
> reference, and wants to go ahead and de-reference, so it has 
> How much of a SIP stack do I need for a SUBSCRIBE/NOTIFY? Is 
> there a suggestion as to how the PC identifies itself in the 
> SIP message (I'm assuming the PC doesn't have an account with 
> a voice service provider, or such, since that wouldn't be 
> good to require of it)? I'm not too clear on how 
> point-to-point SIP works, but where does the PC go to look up 
> the SIP urn that it sends the SUBSCRIBE to, so it has an IP 
> address for routing? Does this need to be hard-coded into the 
> operating system?
> I really am curious, really don't know, and I'm not just 
> pretending to be dumb...
> Barbara
> 
> *****
> 
> 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. GA624
> 
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 16:33:58 -0400

You don't need much of a stack.  The smallest embedded stack could be wacked
in half and work (if it supported SUBSCRIBE/NOTIFY in the first place).  
I think the PC could use the identity it already has from the DSL network
(it has a userid, which it combines with the domain name, as it would for
email).  The PC would take the hostname of the LbyR URL and look for a SIP
SRV record in the DNS, and send the SUBSCRIBE there.

The while transaction looks like:
    SUBSCRIBE sip:[email-masked] SIP/2.0
      Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
      To: <sip:[email-masked]>
      From: <sip:[email-masked]>;tag=xfg9
      Call-ID: [email-masked]
      CSeq: 17766 SUBSCRIBE
      Max-Forwards: 70
      Event: presence
      Accept: application/pidf+xml
      Contact: <sip:[email-masked]>
      Expires: 600
      Content-Length: 0

   F2 200 OK   example.com server->watcher

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
        ;received=192.0.2.1
      To: <sip:[email-masked]>;tag=ffd2
      From: <sip:[email-masked]>;tag=xfg9
      Call-ID: [email-masked]
      CSeq: 17766 SUBSCRIBE
      Expires: 600
      Contact: sip:server.example.com
      Content-Length: 0

   F3 NOTIFY  example.com server-> watcher

      NOTIFY sip:[email-masked] SIP/2.0
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
      From: <sip:[email-masked]>;tag=ffd2
      To: <sip:[email-masked]>;tag=xfg9
      Call-ID: [email-masked]
      Event: presence
      Subscription-State: active;expires=599
      Max-Forwards: 70
      CSeq: 8775 NOTIFY
      Contact: sip:server.example.com
      Content-Type: application/pidf+xml
      Content-Length: ...

      [PIDF Document]

   F4 200 OK watcher-> example.com server

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
        ;received=192.0.2.2
      From: <sip:[email-masked]>;tag=ffd2
      To: <sip:[email-masked]>;tag=xfg9
      Call-ID: [email-masked]
      CSeq: 8775 NOTIFY
      Content-Length: 0

Rosenb

I presume the PC would use the identity it already has for a typical DSL
provider.   

> 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. GA624

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 22:44:21 +0200

Hi Marc,

we discussed the subscription-based mechanism (which is related but not 
equal to the location-by-reference in the generic sense) to ensure that 
the Target is notified when it moves outside a service boundary.

In Section of draft-tschofenig-geopriv-l7-lcp-ps-01.txt we had the 
following text: Note that the LIS provides presence service capabilities.

"

    The following list describes the location subscription idea when the
    end host performs the subscription itself:

    1.  The end host discovers the LIS.

    2.  The end host sends a request to the LIS asking for a location-by-
        reference (or obtains one automatically if the network knows that
        the location might change).

    3.  The LIS responds to the request and includes location and a
        subscription URI.  The URI contains a randomized component.

    4.  The end host takes location information and queries the LoST
        server and acquires the service boundary (e.g., PSAP boundary)
        and a URI (e.g., a PSAP URI).  The service boundary indicates the
        region where the device can move without the need to re-query
        since the returned answer remains unchanged.

    5.  The end host subscribes to the previously acquired URI including
        a location filter (see [3]).

    6.  If the end host moves outside a certain area, indicated by the
        location filter, then it will receive a notification.  The end
        host can re-query LoST to obtain a new service boundary in order
        to update the location filter.
"

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 16:52:17 -0400

> is placed into PIDF-LO rule sets.
I think you have an anonymous identity, and I think you have the ruleset of
the target.  Need some notes that a ruleset could have user identifying
information in it, and that is probably not desirable in this application.

I'm really getting the idea we are going down the wrong path.  I can see
needing a mechanism for a LIS to tell a presence service where a target is.
The target would have to authorize this.  If we did that, is that ALL we
need?

We're re-inventing a limited piece of presence, and talking about all the
same problems of what is the identity, what is the ruleset, what is the
authentication mechanism.  Is location anything special that makes this a
worthwhile endeavor?

> Then, the question remains: How.
I think you do have to have the target upload its rules.  XCAP for example.

> you can just put garbage in there.
I propose to put an anonymous identity there.  The LIS actually knows who
its subscriber is.  It should be able to determine the identity from the
URL, let alone the anonymous identifier in the URL, but no one else should
be able to.  I'm not sure there is any protocol reason for it.  It may be
needed for audit or legal reasons.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 23:13:15 +0200

Hi Brian,

> needing a mechanism for a LIS to tell a presence service where a target is.

Well. With the location-by-reference mechanism you would allow the end 
host to forward it to the presence server in order to again let the 
presence server to contact (potentially subscribe) to the LIS to fetch 
the target's location.

It does not solve our problems with the LIS though.

> authentication mechanism.  Is location anything special that makes this a

We are not reinventing presence. We are just trying to figure out what 
the authorization policies do (or have todo) when the LIS is in the 
access network.

> I think you do have to have the target upload its rules.  XCAP for example.

Fine with me. You noticed that HELD uploads the policies inband instead 
of outband mechanisms using XCAP. There is certainly a performance 
aspect here (if someone cares about roundtrips).

> needed for audit or legal reasons.

I am fine with this if PIDF is OK with it.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 17:18:22 -0400

> its subscriber is.  It should be able to determine the identity from the

I don't know what "knowledge" you assume. In our local case, the 
Columbia network knows your MAC address (and the IP address it 
assigned). That's it.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 17:29:40 -0400

Right.  It would have to use that to identify you.  Having done that, it can
create a PIDF with an anonymous identity which it could, if it needed to,
associate that identity.  Similarly, it could do that with the construction
of the URL.  No one other than the LIS should be able to make that
association.

I don't assume you have any other identity.  There is a need to upload a
ruleset for this identity, and the LCP uses the same identity to get the
LbyR or LbyV.  Some networks do have other identity info, but I think it has
to work with just whatever the LCP identity is.

Brian

> Sent: Wednesday, September 13, 2006 5:18 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Authentication/Authorization Issues: Re: [Geopriv] coming to

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 17:39:20 -0500

> fairly dynamic, sometimes on short time scales ('mutual aid').

I don't think that this is necessarily true.  An access network provider has to have some sort of physical presence to provide an internet link.  This means that they exist in the same jurisdiction as the PSAP (et. al.).  Because both have a link to the physical location, then there is a good possibility that something can be worked out.

In the US, NENA is looking at setting up a certificate authority to certify PSAPs - the possession of a VESA certificate will indicate to a LIS that the requester is a valid emergency entity.  To my knowledge, the number of these credentials required will be smaller than you hint at.  This is a reasonable indication of how to authenticate emergency entities for the retrieval of location information.

Authentication of a LIS is, understandably, a different class of problem.  Like you say, thousands of LISes might exist, with far greater diversity.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 18:58:56 -0400

I do not buy the physical presence argument at all.  For example, I may
outsource the "ESRP", which needs location to route.  Henning's example was
a mutual aid fire company from out of area needing to access current
location.

I think it may be possible to get credentials issued to PSAPs in North
America, although I have been trying diligently for a year to get it started
with zero progress.  Getting every responder who may need location
credentials is MUCH more problematic.  Getting credentials in other areas
may be even more problematic.  And I am an optimist about credentials.

I think we should treat the reference as we do the location.  

Security of reference = security of object

If you got it, you are honor bound to obey the ruleset, but you have the
location.  That means the dereferencer doesn't check credentials.  This does
not imply that privacy and integrity protection is not desirable, but in the
emergency case, you fall back to none.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2006 6:39 PM
> To: Henning Schulzrinne; Hannes Tschofenig
> Cc: GEOPRIV
> I don't think that this is necessarily true.  An access network provider
> has to have some sort of physical presence to provide an internet link.
> This means that they exist in the same jurisdiction as the PSAP (et. al.).
> Because both have a link to the physical location, then there is a good
> possibility that something can be worked out.
> 
> In the US, NENA is looking at setting up a certificate authority to
> certify PSAPs - the possession of a VESA certificate will indicate to a
> LIS that the requester is a valid emergency entity.  To my knowledge, the
> number of these credentials required will be smaller than you hint at.
> This is a reasonable indication of how to authenticate emergency entities
> for the retrieval of location information.
> 
> Authentication of a LIS is, understandably, a different class of problem.
> Like you say, thousands of LISes might exist, with far greater diversity.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Sep 2006 18:16:11 -0500

Marc,

Carrying the requirement argument forward, it is seldom if ever a
requirement for the end-point to have its location. The actual
requirement is that the end point wishes to use a service in the
network, and that the service requires to the end point's location in
order to fulfil the request.

This requirement can be resolved either by the end point having its
location and forwarding it, or by the service making use of a location
reference. Both work.

Perhaps you can state a requirement where the end point wishes to have
its own location independent of a network service?

Cheers
James

> Sent: Thursday, 14 September 2006 4:01 AM
> To: Dawson, Martin; [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 18:26:53 -0500

That's the first time I've heard someone actually claim that as a reason
that i2 doesn't support mobility. It would have been useful to have
raised that point in the actual NENA working group forum. The class of
service discussion is ongoing, and semi-independent, to whether the PSAP
does an update request.

A PSAP receiving a pure geo location for a VoIP call has all the
information it needs to know whether an update request is worth
attempting. The E2 interface semantics already have the support needed
to provide a suitable response if an updated location cannot be
provided. Generally that would be if the VPC only received a
location-by-value and was not provided a location reference. It also
covers the somewhat unusual circumstance of a fixed access network which
provided only a geo but not a location reference. The same applies in a
global context - where in other countries, for example, the MLP protocol
may be used for VPC requests rather than E2.

There are no gaps that prevent the location determination and provision
of updates for a wireless access network. Simply none.

The list I previously sent:

Practical benefits of location reference:
* The literal location does not need to be transmitted in band. Where
the eventual recipient and de-referencer is the only party the "owner"
of location cares to provide disclosure to, then the reference mechanism
achieves this. Particularly useful where the owner is not in a peer
signaling relationship with the de-referencer. E.g. a VoIP emergency
caller and a VPC.

* The location reference form is immutable and generic (i.e. a URI - and
my view that a generic URI is perfectly adequate has also been
expressed). So, no matter what eventual modifications, extensions, or
additions are made to the manner in which the PIDF-LO is formed, the
conveyance path need not be concerned about backward incompatibility.
Adaption is limited to the actual end-user of the location information.

* Where the location owner is not in a peer signaling relationship with
the location user (e.g. a VoIP emergency caller and a VPC), the location
reference can be permitted to be valid for a period of time allowing,
for example, the retrieval of location updates during the period of that
session.

* As a counter-response - no the location reference is not less secure.
Losing privacy of location information means losing the information at
the device or in transit. Loss of a literal location object means the
location is lost in one step. Loss of a reference still requires the
unauthorized party to successfully breach the authentication and
authorization barrier at the referenced server. Location by reference
provides superior privacy.

* The DSIG solution for DHCP/LLDP-MED contributed by Rosen et al
recently does not address the temporal component. Brian should state the
signature also needs to provide an expiry-time component. Else the
signed LO can be replayed at any time in the future from anywhere by the
original recipient. Expiry time semantics are somewhat awkward. Since
de-referencing is an instantaneous process, the location server can
apply temporal rules directly without the need to encode them in the
location object itself.

* Since a LIS can provide many forms of location (Civic, Postal Civic,
Jurisdictional/Emergency civic, Geodetic, and arbitrary other forms that
may be added later) a de-referencing application may request the form
which is of specific interest to it. This obviates the need for the
client device to divine the form in advance of conveyance or to request
and send every possible form of location from the LIS before sending
by-value.

In terms of using location-by-reference to avoid location-by-value - I
believe there are deployment models that will want to do that for any
number of reasons (I articulated the scenario of a scientist tracking a
set of weather balloons providing a low power pulse tracked by uplink
timing measurements). This is a valid application for location reference
and it should be supported. I am not interested in - and it is not
appropriate for a protocol specification to be evaluated on -
requirements defined based on business imperatives. Business models
succeed or fail independently of the protocol specification as long as
the specification supports alternative options.

In terms of the LIS applying policy beyond that provided by the device.
Yes - jurisdictions that provide location for emergency services
regardless of the client policy are an example of that function. 

Cheers,
Martin

> Sent: Thursday, 14 September 2006 3:53 AM
> To: Dawson, Martin; 'Marc Linsner'; 'Andrew Newton'; [email-masked]
> i2, as currently defined, does not support mobility, in that, for
example
> PSAP is needed.  It does not specifically prevent mobility, it is
silent
> You are correct that the architecture was envisioned to cover
mobility,
> 1) Have a requirement that the endpoint NOT get location, while
allowing
> 2) Have a requirement that the LIS control access to location
independent
> > location-by-reference are apparently based on an ideological
criterion
> > > 1) The only requirement that I've been able to glean from the
multiple
> > > years

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 18:49:54 -0500

> Sent: Thursday, 14 September 2006 4:11 AM
> To: Dawson, Martin; 'Henning Schulzrinne'; 'Hannes Tschofenig'
> Cc: 'GEOPRIV'
> For example, suppose there was a massive (disaster) failure that
resulted
> in
[[Martin Dawson] ] This is all nonsense. There is no such thing as
failure safe. A massive failure can take out the entire infrastructure
associated with being able to make a call at all. I repeat that citing
failure conditions as an argument against a protocol mechanism is not
valid.

I can describe how I expect that pure VoIP players will contract with
various network elements across jurisdictional boundaries if you like -
but I'd prefer to do it in a separate thread since this is quite
peripheral to the discussion. Suffice it to say that VPCs operate within
jurisdictional boundaries and VPCs service the request interface to the
emergency call centers that operate within their jurisdiction.
> blown presence system.  The basic mechanism is a pretty simple way to
get
> location out of a LIS.
[[Martin Dawson] ] I wasn't even talking about your proposal of using
sub/not as the request mechanism. I'm not confused on that point at all,
though you seem to have misunderstood my comments above. You think
sub/not should be the mandatory de-reference mechanism; I disagree; but
that has nothing to do with the comments above.

> elements besides location.
[[Martin Dawson] ] It is only a location server - as an IM server is
only an IM server but still displays elements of presence management.
The analogs with a presence server were intended to be illustrative not
prescriptive. Again, you seem to have misunderstood the point being
made.

> presence ruleset provided to control it.
[[Martin Dawson] ] I explicitly agreed with that and, indeed, my
discourse above was in support of that point. The only identity used by
the LIS is a transitory one - for the duration of the context the device
has with the LIS and while visiting the particular access network the
LIS serves.

> do that other ways, and you can use presence to do push.
[[Martin Dawson] ] I haven't been confused on that point so far but I'll
try to avoid it as you request. I can't do it in the migratory VoIP
architecture where the VPC has no such relationship and, indeed, a
presence mechanism is not even assumed as far as VoIP emergency call
contexts. And, certainly, presence infrastructure should not be
required.

> normally be operated by the access network.  I understand the
assumption
> you
> be that the LIS hands the endpoint a reference, which the endpoint
gives
> TO
> would dereference the thing that it gave the endpoint (presence
service is
> to the access network; by definition, the device hands the LIS some
kind
> of
> identity, which the LIS responds to with LbyV or LbyR, so the device
is
> anonymous to the LIS.
[[Martin Dawson] ] If you don't mean identity in terms of the immutable
identity maintained by the presence server, then say so now. That is how
I interpreted you. You can't have a protocol stack without some sort of
identity to communicate with. My view is that the transitory identity
that the LIS is concerned with is the IP address of the device. The
identity that is used for communication in a reference will de-reference
to that IP address but it will be obfuscated so not even that identity
is visible.

  The location object the LIS hands out (to the
> endpoint or another entity presenting a reference) would be anonymous
in
> my
[[Martin Dawson] ] As above, it is transitory in the sense that it only
exists while the device is visiting that access network and while it has
a context with the LIS. It is starkly transitory in comparison to the
relationship the user has with the presence server where this
relationship exists at all times and all places even if the user isn't
connected to any network.

> 
> I agree that the configuration protocol (endpoint to LIS) should be
the
> same
> (between the dereferencer and the LIS) should be the same.  If the LCP
had
> it's a requirement that it be the same protocol, but I think it's very
[[Martin Dawson] ] Uh huh.
> Well, subject to the target's ruleset, right?
[[Martin Dawson] ] If you like - you can write MUST all you like.
Jurisdictions will still apply policy extensions if that is their
nature. Use the democratic process to argue that if you really want to
make a difference.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 19:52:21 -0400

On Sep 13, 2006, at 6:39 PM, Thomson, Martin wrote:

> I don't think that this is necessarily true.  An access network  
> provider has to have some sort of physical presence to provide an  
> internet link.  This means that they exist in the same jurisdiction  
> as the PSAP (et. al.).  Because both have a link to the physical  
> location, then there is a good possibility that something can be  
> worked out.

This isn't necessarily true, as Brian has pointed out repeatedly.  
Back-up PSAPs can be essentially anywhere, not even counting the  
various default call centers that many VSPs operate currently. There  
are at least 6,000 PSAPs in the US and probably many more emergency  
service agencies.

Like I said in my earlier remarks, there is going to be disagreement  
on how easy or hard this it - and no really good way to judge this  
until it's been built and is operational, including details such as  
CRLs.

None of this addresses the more fundamental problem that I believe  
that giving PSAPs "tickets" that allow unrestricted access to  
location information is an extremely dangerous thing to do. Given  
that this is GEO*PRIV*, we might want to consider this. This is far  
more important than adding "please, be nice and observe, if you feel  
like it" rules to PIDF-LO objects.

> certify PSAPs - the possession of a VESA certificate will indicate  
> to a LIS that the requester is a valid emergency entity.  To my  
> knowledge, the number of these credentials required will be smaller  
> than you hint at.  This is a reasonable indication of how to  
> authenticate emergency entities for the retrieval of location  
> information.

You seem to have missed the later part of my message.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 18:59:53 -0500

This is the kind of ideological rhetoric that I object to in an
engineering forum.

* If you don't trust anybody, don't use networks... or just about
anything else. The principle of the LIS is that it's the access network
that can determine location. They don't need an IETF protocol to do
this. Law enforcement agencies can, and do, place warrants on access
providers to obtain location, session data, and session times. They may
do this for sound social good or they may do it for nefarious and/or
oppressive purposes. Their ability to do this is not governed by IETF
spec capabilities and it's an act of hubris to think it is.

* If you want to ensure that ethical controls are placed on these
activities - and the proper standard of staff and organizational
responsibilities - then use the democratic process. You need sound
legislation and an ethical administration. If you don't live in a
democracy, you may need to consider revolution. You will make zero
contribution by trying to project your politics through a protocol
specification.

* There are valid purposes for these mechanisms; trying to deposition
them by sowing seeds of fear is not sound engineering.

Cheers,
Martin

> Sent: Thursday, 14 September 2006 5:03 AM
> To: Brian Rosen
> Cc: Dawson, Martin; 'Hannes Tschofenig'; 'GEOPRIV'
> >> services authority does have the authorization to obtain location
at
the
> had a

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 20:15:36 -0400

> its own location independent of a network service?

Examples include the millions of GPS navigational units in service  
today, many of which are routinely used where data services are  
either unavailable or unreliable.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 20:13:07 -0400

I think it is pointless to discuss this further. I will strongly  
object to any protocol that has such blatant security problems and  
hope that the name of this working group actually means something.  
This has nothing to do with ideology, unless you want to declare  
privacy an "ideology" and we should just trust everybody.

As I pointed out, it doesn't matter whether you trust 'anybody'. A  
protocol with a catastrophic failure mode is not a good engineering  
design, in my view.

Trying to denigrate this by "sowing seeds of fear" is rhetoric, not  
rational argument.

Henning

> providers to obtain location, session data, and session times. They  

I said nothing about not allowing warrants. The mechanism I objected  
to facilitates warrantless spying.

> spec capabilities and it's an act of hubris to think it is.

Lots of engineering organizations have objected, in general, to  
network designs that expose such weaknesses, particularly given that  
there are solutions that do not suffer from such catastrophic failure  
modes.

> contribution by trying to project your politics through a protocol

I didn't know that facilitating warrantless interception was the  
mission of this working group. Thanks for clarifying that.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 20:15:36 -0400

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 20:13:07 -0400

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 19:21:28 -0500

I don't know what the current intent of i3 is - or indeed ECRIT - but
presumably an end-to-end IP location call can be quite sophisticated as
far as how location updates are acquired.

You've probably noticed, I'm most concerned with facilitating getting i2
working without barriers being introduced by IETF protocol anomalies
(i.e. I'd prefer it if IETF protocols could be used).

In i2, the VPC queries the LIS. The VPC is a hub for all the PSAPs and
PSAPs are a hub for all the police and etc. Each hub has to have its own
authorization architecture - and does in the legacy emergency network.
The LIS, however, is only concerned with the VPCs. VESA certificates for
VPCs are the intended mechanism. The scale should be quite manageable.

Perhaps i3/ECRIT should consider a similarly scalable hierarchy.

Authenticating the LIS identity is actually a separate issue. Again, i2
proposes VESA certificates provided to broadband access infrastructure
providers (not ISPs necessarily). However, this is about providing
location integrity - ensuring the emergency network has confidence in
the source of the location information. It is the same concern as exists
with respect to location-by-value.

I believe a LIS will always be in the same jurisdiction as the VPC - and
the VPC will always be in the same jurisdiction as the emergency call
center. The VSP may be cross-jurisdictional to these entities. While
this doesn't impact the protocols themselves, I believe it will be
structured this way to maintain jurisdictional integrity.

Cheers,
Martin

> Sent: Thursday, 14 September 2006 8:59 AM
> To: Thomson, Martin; 'Henning Schulzrinne'; 'Hannes Tschofenig'
> Cc: 'GEOPRIV'
> outsource the "ESRP", which needs location to route.  Henning's
example
> was
> location.  That means the dereferencer doesn't check credentials.
This
> does
> not imply that privacy and integrity protection is not desirable, but
in
> > I don't think that this is necessarily true.  An access network
provider
> > certify PSAPs - the possession of a VESA certificate will indicate
to a
> > LIS that the requester is a valid emergency entity.  To my
knowledge,

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 20:22:27 -0400

> signaling relationship with the de-referencer. E.g. a VoIP emergency

I don't understand this argument. Given my previous message, this is  
likely to be a disadvantage.

> Adaption is limited to the actual end-user of the location  

Not true. If the location is actually provided by the end system, the  
LIS has to convert to the new format.

> for example, the retrieval of location updates during the period of  

This is just as true for in-band.

> provides superior privacy.

We have gone through this. So far, all of the proposed mechanism  
either give thousands of entities unrestricted access or have likely  
failure modes.

> apply temporal rules directly without the need to encode them in the

This is a detailed design issue, which we can resolve once we decide  
what is useful about signed locations.

> and send every possible form of location from the LIS before sending

So far, only 2 1/2 forms have been identified as useful (civic +  
postal city, geo). The likelihood that a random LIS will have 17  
different formats seems low, particularly where these are derived  
from information actually provided by the end system, via GPS or  
Galileo. New forms are only useful if they can be widely supported by  
end-system derived location sensors, not just network TOA and similar  
systems.

I agree with Marc that this essentially leaves the "we don't trust  
the end system" argument.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 19:29:54 -0500

There is no "catastrophic failure mode" and citing circumstances outside
the scope of the protocol do not reflect on the protocol. Actually
privacy is an ideology. However, I could take the position that this
group be disbanded in the interests of its "name" because I can cite an
arbitrary number of circumstances under which information in a presence
server, including location, may become compromised.

I agree it's a pointless discussion which is why I advise not to use
such scenarios to criticize a protocol element. It results in wasted
effort and increasingly moot discussion.

Cheers,
Martin

> Sent: Thursday, 14 September 2006 10:13 AM
> To: Dawson, Martin
> Cc: GEOPRIV
> >>> reliably, I don't want to create a situation in which a failure
here
> >> causes
> >> table (which roughly describes the one in my town) the capability
to
> > do
> >> bad actor can get the location information of the whole citizenry
of
> >>> whether it's LbyR or LbyV.  It does not follow that the
dereference
> >> protocol
> >>> policy upload function, I would consider that a good thing.  I'm
not
> >> sure
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 21:05:47 -0400

> like it" rules to PIDF-LO objects.
I believe I agree with you, but I want to check my premises.

I think if you give your location by value to anyone, including a PSAP, they
can, if they want to, ignore your ruleset and send it to anyone.

I believe we should treat the reference the same way: assume that if you
have it, the target authorizes you to get location, with the ruleset.

This is security of object = security of reference

I don't think you mean to have the reference have any more, but certainly no
less security than the object itself.

So, it's kind of a ticket, but we aren't proposing to use authentication of
the watcher as some additional security to the location information:
possession of the reference is the same as possession of the location.

That means we use our security mechanisms to restrict who gets the
reference, exactly as we would use them if it was the object.

Is that your position?  It is mine.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 20:20:45 -0500

> Sent: Thursday, 14 September 2006 10:22 AM
> To: Dawson, Martin
> Cc: Brian Rosen; Marc Linsner; Andrew Newton; [email-masked]
[[Martin Dawson] ] I'll explain some more then. If there are an
arbitrary number of nodes between the device and the intended recipient
of the location information (e.g. proxies) and the device does not
necessarily trust those intermediate nodes then a location reference
does not expose the actual location value to those nodes. The
intervening nodes do not have authority to dereference the location
whereas the intended recipient does.
This secures the location information particularly where there is no
opportunity for encryption of a location value between the device and
the intended recipient.

> LIS has to convert to the new format.
[[Martin Dawson] ] Exactly, the LIS is dedicated to location, it is
maintained and must deal with the mutable aspect of location form.
However the many and arbitrary future conveyance protocols that are
otherwise unconcerned with PIDF-LO (and that includes the client end
implementation of those protocols that need to transcode the PIDF-LO
received from the LIS into the conveyance protocol) are then insulated
from the mutable aspects of the PIDF-LO form. At a second order level,
as the semantics of LIS interaction evolve, the device and conveyance
protocols are insulated from these changes. The elements most concerned
with location - the application itself and the LIS are all that need to
be maintained to current specifications and capabilities.

> This is just as true for in-band.
[[Martin Dawson] ] I disagree. In i2, the VPC does not have a peer
signaling relationship with the device. It has no way to get an updated
location except by being provided with some alternative reference from
which location updates can be obtained.

> either give thousands of entities unrestricted access or have likely
[[Martin Dawson] ] See other sub-thread. This is citing spurious and
external failures in implementation of non-related infrastructure. I
certainly agree we've gone through it.
> what is useful about signed locations.
[[Martin Dawson] ] Nevertheless, instantaneous location retrieval by
de-referencing obviates the complexity of establishing temporal
integrity. It is a benefit.

> the end system" argument.
[[Martin Dawson] ] While other threads have focused very narrowly on
emergency services, and yet other threads are ridden with assumptions
about voice or SIP applications, and still others assume that LIS are
only relevant in public carrier networks, the fact is that we should not
be assuming any specific application domains. The form of location may
be very much manifold when the many useful application domains are
considered. This includes domain-specific representations of location
(e.g. train stations and rail segments for a closed system that monitors
rail traffic). Being able to use a standard LIS client - which includes
the ability to obtain a location reference - is of value to the
implementers of such systems for the obvious reason that they can use
commodity software.

Now - something that I have been pondering is whether people feel that
the PIDF-LO does have a very specific application domain - in support of
a very specific set of functions associated with presence; e.g. is the
location information to be restricted to the location of people for
example. I have been an advocate of using PIDF-LO because it's a well
thought out generic structure for representing useful forms of location
- and am less interested in its application for presence. If there are
constraints on the form of location then perhaps I should be advocating
a separate or new location encoding schema. Which is the case - PIDF-LO
is intended/expected to have utility outside of presence or it is to be
restricted to functionality that supports presence?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 21:29:34 -0400

> can, if they want to, ignore your ruleset and send it to anyone.

Indeed. But they only get my location during an emergency call, which  
presumably is a rare event.

> have it, the target authorizes you to get location, with the ruleset.

Right.

> This is security of object = security of reference

Indeed, but this is only true if the reference doesn't give  
unrestricted access to the object.

To be concrete: suppose I build that system that allows anybody that  
has my AOR and a VESA cert to get my location at any time. This is  
far *less* secure than conveying in-band location, which limits my  
risk to one exposure, and only if I'm unlucky enough that the PSAP  
I'm talking to is misbehaving. In other words, rather unlikely.

There are solutions, such as time-limited tokens, that don't have  
this catastrophic failure mode.

> less security than the object itself.

This strongly depends on the characteristic of the reference. If the  
reference is not time-limited, it is far *less* secure, for the  
reasons I mentioned.

> Is that your position?  It is mine.

I think the statement security(reference) = security(value) is too  
simplistic. I think a more accurate, but less pithy statement is

exposure(reference) = exposure(all values for lifetime of reference)

and even that's probably not quite right if the reference relies on  
querier authentication exclusively. Thus, we need to be far more  
specific about the reference. There are at least three kinds:

(1) something guessable (your AOR, your phone number) or something  
densely packed (an identifier where just about every identifier value  
is meaningful, so that I can just walk the identifier space until I  
find something interesting).

(2) something crypto-random, but permanent (anybody who can intercept  
the reference can get your location forever)

(3) something random and very temporary

Only a reference with property (3) has defendable security properties  
that are roughly equivalent to a by-value transmission.

I don't think authentication adds much value here. Any system that  
gives thousands of users access to any information, without need-to- 
know, can't be secure since a single "mistake" exposes the private  
data of all users. We know that mistakes happen in cert issuance,  
even for high-profile names like Microsoft. Alternatively, breaking  
into a single PSAP system, physically or electronically, will  
retrieve the necessary signing material to get full access to any  
user's location data. This is no different than handing out the same  
"secret" key to thousands of users and hoping that it stays secret.  
We might as well have a global "root" password for all routers or  
Linux servers...

This isn't a protocol flaw as such, but a fundamental security design  
flaw. In my view, a distinction without a difference.

There are several examples of such catastrophic system failures. Two  
I know about are satellite access keys and DVDs, where indeed the bad  
design of a single DVD player compromised the whole DVD DRM security  
architecture. Needless to say, the successor architectures changed  
the "protocol".

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 21:41:39 -0400

This isn't NENA.  There is a meeting next week where you can ask the i2.5
folks if they believe mobility is well specified in the current document.

> signaling relationship with the de-referencer. E.g. a VoIP emergency
Your example is pretty poor because the LIS does not know who must route the
call based on location.  It must allow anyone with the reference to get
location to route.  The mechanism explicitly does not restrict any proxy on
the path from routing based on location.  It encourages this early, but the
LIS has no idea what that means.

I'm intrigued with the word "owner".  You didn't use "target", "user" or
"endpoint".  Did you mean to imply that, for example, the access network
could claim it is the owner, and therefore is in control of the ruleset?  I
think we would disagree with that.

If the "owner" is indeed the target (or the user associated with the
target), and it does know the "eventual recipient", then it could
straightforwardly send location to that recipient.  For example, it could
S/MIME encrypt it with the key of that recipient.  We're assuming here that
the attached ruleset is not sufficient security, which is reasonable.  You
said "owner is not in a peer signaling relationship", but if you can pass
the reference, you can pass the value.

I generally think presence is the kind of thing you probably want to use
here, especially if the device is mobile.

> Adaption is limited to the actual end-user of the location information.
This is also a characteristic of XML, which is how PIDF is formed.  So the
LbyR has the same characteristic.

> for example, the retrieval of location updates during the period of that
Well, the thing is here that you are talking about updates.  If you were
just using LbyV, you would get your update from the endpoint, and it would
control how long you were allowed to see the data.  If the endpoint is
willing to give location for emergency calls, than it is willing to give it
to the VPC.  It would allow a "peer signaling relationship" for this
purpose.

Also a presence mechanism, of course.

> provides superior privacy.
Here we just disagree.  I think many of us don't believe we can create a
sufficiently robust authentication system.  We may need a rough consensus
determination on this point.  I wish it were true, I don't think it is.

> apply temporal rules directly without the need to encode them in the
I agree.  All forms of LbyV should have a timestamp, they should have a TTL
and those should be in a signature if there is one

> and send every possible form of location from the LIS before sending
This is a protocol issue: if the protocol supports the client requesting the
type of location, then the server can respond.  While I agree that the
endpoint is unlikely to contain a geocoder, it can ask for both forms from
the LIS and then supply whatever form the client wishes.  If the protocol
doesn't have this feature, then of course you can't get that result.

> the specification supports alternative options.
Agree that a business model doesn't make a good requirement for a protocol,
but it sure wouldn't be the first time this has happened.  The current L7
discussion is highly influenced by business models of one form or another
and not on engineering issues.  Before you yell, I think there are
sufficient actual requirements to do an L7 protocol.

I don't believe your example is particularly valid. I think you can do LbyV
as easily as LbyR and have fewer problems.  YMMV.  I think I want to see a
requirement that is clear cut.  It's one thing to say that, for example, not
every network can be configured to support DHCP and/or LLDP-MED in such a
way that it is possible to support location solely by that mechanism.  I can
say that such networks might be few and far between, but they exist, and
will exist.  That is a requirement for at least another protocol, if not an
L7 protocol.

What is the actual requirement that drives LbyR?

ps - I really don't believe we are going to abandon LbyR, because we have
presence, and presence is LbyR.  Even assuming that presence is the ONLY
LbyR we do, it still does what you want it to do.  Still, it would really be
nice to have a crisp requirement that we could all agree on.

> regardless of the client policy are an example of that function.
Yeah, sort of.  What you imply is that the endpoint can withhold anything it
doesn't want to give the PSAP, regardless of what the law says.  True,
although I don't think we engineer protocols around that.  The problem with
your argument is that the endpoint can refuse to send the reference, and
unless the VSP can supply it (which depends on the VSP relationship with the
access network), the LIS can't help.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 21:43:30 -0400

I agree with all of this.
Thanks

Brian

> Sent: Wednesday, September 13, 2006 9:30 PM
> To: Brian Rosen
> Cc: GEOPRIV

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 21:32:00 -0500

Paranoia rules... by "owner" I intended the "user" of the "device" which
constitutes the "target" of the location determination. That's all I
meant.

> Sent: Thursday, 14 September 2006 11:42 AM
[[Martin Dawson] ] :) classic.

> Your example is pretty poor because the LIS does not know who must
route
> location to route.  The mechanism explicitly does not restrict any
proxy
> on
> the path from routing based on location.  It encourages this early,
but
> LIS has no idea what that means.
[[Martin Dawson] ] In i2 the call server asks the VPC for routing
information. If it provides a reference in that request then the VPC
de-references and requests the location from the LIS. The call server is
not authorized to dereference, the VPC is. Beats the heck out of me why
that's a poor example.

>From a previous post, you stated you didn't think the LIS would apply
authentication/authorization to permit de-referencing. I certainly don't
agree with that but perhaps it explains your comment above.

> could claim it is the owner, and therefore is in control of the
ruleset?
> I
[[Martin Dawson] ] Bang bang bang - nice brick wall... in i2 there is no
peer signaling relationship between the VPC and the device. The VPC
needs an alternative route to obtain updated locations. The device can't
provide an arbitrary future location by value in the call initiation.

> here, especially if the device is mobile.
[[Martin Dawson] ] Well maybe. But we cannot require presence for
emergency services support. Hey, I thought the vision of i3 was to
eliminate all forms of "operator"... ;) A presence operator is
conceptually an evolution of an HLR operator running a cellular network.
Now VoIP emergency callers are chained to a presence operator?

> LbyR has the same characteristic.
[[Martin Dawson] ] Ideally, but backward incompatibilities still occur
with XML specifications. Been working in OMA on the MLP spec by any
chance? Insulating the conveyance from such artifacts is a benefit. I
listed it in the benefits.

> willing to give location for emergency calls, than it is willing to
give
> Also a presence mechanism, of course.
[[Martin Dawson] ] Bang, bang, bang... If I don't have a network
topology that includes a peer signaling relationship with the device
and/or works independently of presence functions (e.g. the i2
architecture), I don't have that luxury.

> determination on this point.  I wish it were true, I don't think it
is.
[[Martin Dawson] ] Then, presumably, you don't use on-line banking
either. A very hackneyed conversation. If you can come up with another
and more reliable way to convey identity in the Internet where there is
a relationship decoupling between the client and the server other than
certificates, then you can make yourself a fortune. As far as I know,
the only way that this can be done is by certificates and public key
encryption using evolving ciphers. It is a consequence of the Internet
services model - and goes way beyond the narrow application domain of
emergency services. It's why architectures such as FIPS have been
developed - because cert management is the cost of reaping the benefit
of this decoupling. If it can't be made to work, then many service
concepts are doomed. I believe it can work. While you recently described
yourself as a "cert optimist" I mostly hear you advocating despair. I
absolutely agree - we just disagree :).

> I agree.  All forms of LbyV should have a timestamp, they should have
a
> TTL
[[Martin Dawson] ] Quite right - that's the solution we have proposed
for inclusion in the location value DSIG. However, how long should it
be? Will it be long enough for the intended purpose? Alternatively,
should it be a UTC timestamp and should the recipient apply the policy
on how long is long enough or does the client/LIS somehow mandate that?
When a location is obtained by instantaneous de-reference, the location
user has no doubt that the location is instantaneously applicable to the
target in question. This is easier and less ambiguous. It's a benefit of
location reference; so I list it.

> This is a protocol issue: if the protocol supports the client
requesting
> doesn't have this feature, then of course you can't get that result.
[[Martin Dawson] ] But, of course, if there are many useful forms of
location a LIS can provide (or do you claim we have now identified all
present and possible useful forms of location?) then the device has to
either ask for them all or work out what the application really needs.
Since a dedicated session between the application and LIS allows the
application to request the form it really needs, this complexity is
eliminated. That's a benefit. The device implementation of the protocol
may not know about the new form but the application would (by
definition, since that's what it's interested in). The device
implementation doesn't need to if it just asks for a reference. That's a
protocol evolution benefit, so I list it.

> sufficient actual requirements to do an L7 protocol.
[[Martin Dawson] ] Of course, discussions are influenced by business
models. Most forums start with some form of self-interest, including a
desire to provide a social service. With sufficient broad
representation, the protocol should have sufficient options to satisfy
the individual needs, without bias toward or against one or the other,
as efficiently as possible, and without internal contradiction.

> requirement that is clear cut.  It's one thing to say that, for
example,
> way that it is possible to support location solely by that mechanism.
I
> can
> will exist.  That is a requirement for at least another protocol, if
not
> an
[[Martin Dawson] ] Bang, bang, bang...
> LbyR we do, it still does what you want it to do.  Still, it would
really
> be
[[Martin Dawson] ] I don't want to have to have a presence server
subscription to be able to use Internet based location services. For
example, if I want to use a speed-camera alert web application that uses
location updates directly via the provided reference to my WiMAX
provider's LIS, I don't want to *have* to be using a presence service. I
might add that the assumption of such a requirement would seem to be at
odds with much of the opinion previously expressed by some.

> Yeah, sort of.  What you imply is that the endpoint can withhold
anything
> unless the VSP can supply it (which depends on the VSP relationship
with
> access network), the LIS can't help.
[[Martin Dawson] ] I wasn't attempting to imply the point you inferred.
You'd asked whether I thought the device provided policy would be the
only policy applied. I don't think that is the case - neither do you
from comments made elsewhere. Other than that, what's your point? If
location is not provided by either value or reference by the device than
emergency call processing by a pure VoIP provider can't proceed? Uh...
yes.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 21:45:31 -0500

So.. ah... satellite (TV receiver I assume you mean?) and DVD encryption
keys suffered from the vulnerability that the keys are static and the
resource that tested the key was replicated to mass market deployed
devices.

The "new generation" of DRM that you allude to relies on network access
for authorization, has temporal validity windows, and relies on public
key encryption. That is, they are moving to the same sort of
architecture being adopted to control LIS access. VESA as prescribed by
NENA provides the analog of the control the DRM servers developed for
contemporary digital media distribution/protection. FIPS is specified to
ensure that entities such as VESA and the VPC operators apply the right
controls to cert management. It is a jurisdictional issue to ensure that
standards such as FIPS are a requirement.

You may not feel confident in this technology but it's what the world
currently has. And it's vital to far more than controlling access to
location by emergency services. Rather than avoid developing systems
that make use of such technology, then, perhaps it would be better to
focus on evolving and improving that particular technology. Whatever is
used for authentication once you do provide these improvements will be
equally applicable to location references - and, for that matter, to
digital signatures on location by value, so both ends of the location
food chain can benefit from the effort.

Cheers,
Martin

> Sent: Thursday, 14 September 2006 11:30 AM
> To: Brian Rosen
> Cc: GEOPRIV

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Sep 2006 09:35:18 -0400

Martin,

You are asking the IETF to fix design flaws for NENA i2?  Why don't you fix
i2?

-Marc- 

> Sent: Wednesday, September 13, 2006 8:21 PM
> To: Brian Rosen; Thomson, Martin; Henning Schulzrinne; Hannes 
> Tschofenig
> Cc: GEOPRIV
> I don't know what the current intent of i3 is - or indeed 
> ECRIT - but presumably an end-to-end IP location call can be 
> quite sophisticated as far as how location updates are acquired.
> 
> You've probably noticed, I'm most concerned with facilitating 
> getting i2 working without barriers being introduced by IETF 
> protocol anomalies (i.e. I'd prefer it if IETF protocols 
> could be used).
> 
> In i2, the VPC queries the LIS. The VPC is a hub for all the 
> PSAPs and PSAPs are a hub for all the police and etc. Each 
> hub has to have its own authorization architecture - and does 
> in the legacy emergency network.
> The LIS, however, is only concerned with the VPCs. VESA 
> certificates for VPCs are the intended mechanism. The scale 
> should be quite manageable.
> 
> Authenticating the LIS identity is actually a separate issue. 
> Again, i2 proposes VESA certificates provided to broadband 
> access infrastructure providers (not ISPs necessarily). 
> However, this is about providing location integrity - 
> ensuring the emergency network has confidence in the source 
> of the location information. It is the same concern as exists 
> I believe a LIS will always be in the same jurisdiction as 
> the VPC - and the VPC will always be in the same jurisdiction 
> as the emergency call center. The VSP may be 
> cross-jurisdictional to these entities. While this doesn't 
> impact the protocols themselves, I believe it will be 
> > America, although I have been trying diligently for a year 
> to get it 
> > started with zero progress.  Getting every responder who may need 
> > location credentials is MUCH more problematic.  Getting 
> credentials in 
> > other
> areas
> > > > thousands of entities within a particular jurisdiction. 
> Both sets
> are
> > > This means that they exist in the same jurisdiction as 
> the PSAP (et.
> > al.).
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.
> > >

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Sep 2006 09:53:21 -0400

James,

Following your line of thinking, we can probably deprecate all the following
protocols and their variants:

ftp
smtp
pop
imap
http
nfs
and the list goes on....

Afterall, the client really doesn't care about application data, only the
resultant computation/rendering performed on such, which you are advocating
is best done off-board of the host.  I believe we could revive 3270 to
handle all your needs, saving thousands of dollars on client
cpu/memory/software purchases.

The bottom line is, this community agreed to the requirement(s) that an end
host needs to know it's location by value, but hasn't yet agreed to such wrt
location by reference.  I suggest you provide convincing arguments towards
that end versus questioning the need for previous work.

-Marc-

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Wednesday, September 13, 2006 7:16 PM
> To: Marc Linsner; Dawson, Martin; [email-masked]
> Carrying the requirement argument forward, it is seldom if 
> ever a requirement for the end-point to have its location. 
> The actual requirement is that the end point wishes to use a 
> service in the network, and that the service requires to the 
> end point's location in order to fulfil the request.
> 
> This requirement can be resolved either by the end point 
> having its location and forwarding it, or by the service 
> making use of a location reference. Both work.
> 
> Perhaps you can state a requirement where the end point 
> wishes to have its own location independent of a network service?
> 
> Cheers
> James
> 
> 
> > > cellular mobile interfaces and *most
> > > definitely* supports mobile devices. That's one of the 
> main reasons 
> > > that the V3 interface exists.
> > 
> > I view the i2 V3 interface in the same category as L by R in sip 
> > conveyance and L by R in the L7 LCP design team work.  None 
> of these 
> > answer the
> basic
> > > As far as I know it is primarily the detractors of location by 
> > > reference who continue to raise the "business model benefit" and 
> > > it's done so as some kind of anti-benefit statement presumably to 
> > > discredit the entire concept by association. Objections to this 
> > > particular use location-by-reference are apparently based on an 
> > > ideological criterion that has no place in the engineering of a 
> > > protocol that provides useful functions to those that want to 
> > > implement them.
> > 
> > My mention of the business model was actually demonstrating 
> a positive
> for
> > Not necessary to repeat.  I read this prior to drawing my 
> conclusions 
> > below.
> > > > 	b) The i2 architecture defines a 'gateway' 
> between the VoIP
> > > world
> > > > and the legacy.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:19:17 +0200

Hi Martin,

I don't know the details of the i3 infrastructure but this seems pretty 
complicated. I wonder why NENA does not go for a simple solution, namely:

* Pass location information to the end host
* Use SIP location conveyance
* Done

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:19:22 +0200

Hi Martin,

I am confused by your list of advantages of location-by-reference.

Please find some comments below:

> signaling relationship with the de-referencer. E.g. a VoIP emergency

I don't understand what the advantage of this should be.

> Adaption is limited to the actual end-user of the location information.

I don't understand this backward compatibility argument.

> for example, the retrieval of location updates during the period of that

Hmm. Again, I am lost.

> provides superior privacy.

We concluded 
that:security(location-by-value)=security(location-by-reference) BUT

complexity(location-by-value)<complexity(location-by-reference).

If you additionally consider authentication and authorization of the 
Location Recipient towards the LIS with the dereferencing step then you 
have:

complexity(location-by-value)<<complexity(location-by-reference).

> apply temporal rules directly without the need to encode them in the

In the discussions so far most people (including myself) couldn't see 
location signing being particularly useful.

The details for location signing could be worked out even for DHCP and 
other protocols but I don't see it being particularly useful.

> and send every possible form of location from the LIS before sending

That's why we do standardization. We specify what information is being 
transmitted.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:19:17 +0200

Hi Martin,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:19:22 +0200

Hi Martin,

Hmm. Again, I am lost.

We concluded 

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 09:19:34 -0500

If there were design flaws in i2, I wouldn't ask the IETF to fix them -
no. Since there aren't any that I'm aware of I guess I don't need to
deal with that dilemma in any case.

Silly

Cheers,
Martin

> Sent: Thursday, 14 September 2006 11:35 PM
> To: Dawson, Martin; 'Brian Rosen'; Thomson, Martin; 'Henning
Schulzrinne';
> 'Hannes Tschofenig'
> You are asking the IETF to fix design flaws for NENA i2?  Why don't
you
> fix
> > > I do not buy the physical presence argument at all.  For example,
I
> > > If you got it, you are honor bound to obey the ruleset, but you
have
> > > > has to have some sort of physical presence to provide an
internet
> > link.
> > > > Because both have a link to the physical location, then there is
a
> > good
> > > > number of these credentials required will be smaller than you
hint
> > at.
contain

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:19:45 +0200

Hi Brian,

> have it, the target authorizes you to get location, with the ruleset.

With the reference it is not the Target that creates the reference but 
rather the LIS. Hence, it is the LIS that authorizes and not the Target.

> possession of the reference is the same as possession of the location.

Yes.

> Is that your position?  It is mine.
To repeat my position here, if location-by-reference is actually useful:

NO authentication and authorization of the Location Recipient by the LIS 
when dereferencing the location information.

Since this is hard to enforce I would very much prefer location-by-value.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:19:53 +0200

Hi Martin,

please find my response below:

> whereas the intended recipient does.

Intermediate nodes can be prevented from dereferencing using other 
mechanisms, namely end-to-end security. This is far more lightweight 
than using authorization when the Location Recipient fetches location.

I see a major deployment burden in the way you want to use location by 
reference.  I see the need to setup a (possible charging) infrastructure 
    to have Location Recipients needing a relationship with the 
LIS/acces provider.

> the intended recipient

I don't really understand your arguments. What other future location 
conveyance protocols do you see beyond SIP. If there is interest to work 
on other protocols then we should do so. You have to standardize the 
ability to convey a reference in these protocols anyway.

> which location updates can be obtained.

I don't know the terminology but I wonder why updated location 
information is needed at all. If the end host thinks it should send 
updated location then he can do so.

> integrity. It is a benefit.

What is temporal integrity?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:20:04 +0200

If NENA is going along this path then I am seriously concerned about the 
complexity they create just to support some broken business models.

This has nothing todo with security benefits.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:20:01 +0200

Hi Henning,

Henning Schulzrinne schrieb:
> Indeed, but this is only true if the reference doesn't give unrestricted 
> access to the object.
> 
> To be concrete: suppose I build that system that allows anybody that has 
> my AOR and a VESA cert to get my location at any time. This is far 
> *less* secure than conveying in-band location, which limits my risk to 
> one exposure, and only if I'm unlucky enough that the PSAP I'm talking 
> to is misbehaving. In other words, rather unlikely.

I agree.

> 
> There are solutions, such as time-limited tokens, that don't have this 
> catastrophic failure mode.
> 
> 
> reference is not time-limited, it is far *less* secure, for the reasons 
> I mentioned.

I always assumed in the location-by-reference discussion we assume the 
properties outlined in the Geopriv-L7 design team draft.

> densely packed (an identifier where just about every identifier value is 
> meaningful, so that I can just walk the identifier space until I find 
> something interesting).
> 

I agree and that's what I referred to when I spoke about 
security(reference) = security(value)
Additionally, I also assumed that the Location Recipient is allowed to 
retrieve the location object only based on the possession of the 
reference. No authorization by the LIS.

> 
> I don't think authentication adds much value here.

It does not add value from a security point of view. It is very useful 
if you want to setup a complex infrastructure to tie Location Recipients 
(e.g., PSAPs, pizza shops, etc.) to access network providers. A flavor 
of net neutrality.

  Any system that gives
> thousands of users access to any information, without need-to-know, 
> can't be secure since a single "mistake" exposes the private data of all 
> users. We know that mistakes happen in cert issuance, even for 
> high-profile names like Microsoft. Alternatively, breaking into a single 
> PSAP system, physically or electronically, will retrieve the necessary 
> signing material to get full access to any user's location data. This is 
> no different than handing out the same "secret" key to thousands of 
> users and hoping that it stays secret. We might as well have a global 
> "root" password for all routers or Linux servers...
> 
> There are several examples of such catastrophic system failures. Two I 
> know about are satellite access keys and DVDs, where indeed the bad 
> architecture. Needless to say, the successor architectures changed the 
> "protocol".
> 
> 
>
Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 09:22:26 -0500

Nobody has suggested, that I'm aware of, that location by value be
deprecated. What are you actually saying?

Cheers,
Martin

> Sent: Thursday, 14 September 2006 11:53 PM
> To: Winterbottom, James; Dawson, Martin; [email-masked]
> The bottom line is, this community agreed to the requirement(s) that
an
> end
> host needs to know it's location by value, but hasn't yet agreed to
such
> wrt
> > > > This piece of misinformation about i2 continues to be
promulgated.
> > The
> > > > > underlying requirements.  In other words, what problem is L by
R
> > > > solving
> > > > > 3) The citation of the NENA i2 architecture failing for
wireless
> > > > devices
> > > > > > routing.  Therefore, location-by-reference may not
appropriate
> > or
contain

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 09:38:10 -0500

G'day Hannes,

What is the end host that you're referring to?

In i2 - which is specifically designed to get emergency services support
now (without having to wait for when we can replace the CPE in thousands
of devolved PSAPs) - delivers the call through an IP to switch circuit
gateway, through a tandem exchange (selective router), and on to the
PSAP on primarily CAMA trunks. PSAPs only have the ability to query for
location through an ALI - you can't swim back upstream through all that
legacy interconnect to initiate a request for location conveyance. i2
re-uses the cellular infrastructure to query the equivalent of a mobile
position center (the VoIP position center) which provides both the
routing function and the location caching and update function.

i3 may support call-associated conveyance for location updates but it is
not a characteristic of i2. The purpose of i2 is to allow VoIP telephony
to become mainstream by having full E911 support in the migratory period
between now and when IP telephony exists from all callers and to all
PSAP end points. Given the architecture is now defined (a lot of work to
get there) and is now being communicated to the PSAP, ALI, VoIP
provider, and access provider participants in the emergency industry, I
am particularly keen to ensure that the IETF doesn't throw a spanner in
the works. For example, that is why I have been advocating the reference
conveyance in the SIP thread - it's needed to support i2.

Cheers,
Martin

> Sent: Friday, 15 September 2006 12:19 AM
> To: Dawson, Martin
> Cc: Brian Rosen; Thomson, Martin; Henning Schulzrinne; GEOPRIV
getting i2
> >> America, although I have been trying diligently for a year to get
it
> >> started
have
> >>> This means that they exist in the same jurisdiction as the PSAP
(et.
> ------------------------
> ------------------------

---

From: Andrew Newton <[email-masked]>
Date: Thu, 14 Sep 2006 11:04:18 -0400

> This has nothing todo with security benefits.

Not to pick on Hannes directly, but the statements about "stupid" or 
"broken" business models need to be toned down.  Last I checked, communism 
has been nothing but a total failure, and we all need to get over the fact 
that at some point, some where, no matter if we work in a commercial 
research institution or academia or respond to email in between bouts of 
shouting at C++ compilers, somebody has to earn revenue and make a profit.

I think we can reasonably discuss the viability of having a deployable 
system that has as a prerequisite universal access also serving more closed 
environments for commercial purposes, but I think it should be clear to all 
of us that mortgages must be paid and food must be purchased.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Sep 2006 11:14:09 -0400

Read James' email.  He is asserting that application data is not needed at
the target/host, only the computational result derived from said data.  I'm
simply suggesting that is true of many applications, but attempting to point
out how absurd this idea is since the world has moved to intelligent end
points.

-Marc-

> Sent: Thursday, September 14, 2006 10:22 AM
> To: Marc Linsner; Winterbottom, James; [email-masked]
> Nobody has suggested, that I'm aware of, that location by 
> value be deprecated. What are you actually saying?
> 
> Cheers,
> Martin
> 
> > Following your line of thinking, we can probably deprecate all the 
> > following protocols and their variants:
> > 
> > ftp
> > smtp
> > pop
> > imap
> > http
> > nfs
> > and the list goes on....
> > 
> > Afterall, the client really doesn't care about application 
> data, only
> the
> > resultant computation/rendering performed on such, which you are 
> > advocating is best done off-board of the host.  I believe we could 
> > revive 3270 to handle all your needs, saving thousands of 
> dollars on 
> > client cpu/memory/software purchases.
> > 
> > > requirement for the end-point to have its location.
> > > The actual requirement is that the end point wishes to 
> use a service 
> > > in the network, and that the service requires to the end point's 
> > > location in order to fulfil the request.
> > >
> having its 
> > > location and forwarding it, or by the service making use of a 
> > > location reference. Both work.
> > >
> > > Perhaps you can state a requirement where the end point wishes to 
> > > have its own location independent of a network service?
> > >
> > > Cheers
> > > James
> > >
> > >

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Sep 2006 11:17:54 -0400

Of course you don't see design flaws in i2, it supports your argument!

-Marc- 

> Sent: Thursday, September 14, 2006 10:20 AM
> To: Marc Linsner; Brian Rosen; Thomson, Martin; Henning 
> Schulzrinne; Hannes Tschofenig
> Cc: GEOPRIV
> If there were design flaws in i2, I wouldn't ask the IETF to 
> fix them - no. Since there aren't any that I'm aware of I 
> guess I don't need to deal with that dilemma in any case.
> 
> Silly
> 
> Cheers,
> Martin
> 
> > > I don't know what the current intent of i3 is - or indeed ECRIT - 
> > > but presumably an end-to-end IP location call can be quite 
> > > sophisticated as far as how location updates are acquired.
> > >
> > > protocol anomalies (i.e. I'd prefer it if IETF protocols could be 
> > > used).
> > >
> > > In i2, the VPC queries the LIS. The VPC is a hub for all 
> the PSAPs 
> > > and PSAPs are a hub for all the police and etc. Each hub 
> has to have 
> > > its own authorization architecture - and does in the legacy 
> > > emergency network.
> certificates 
> > > for VPCs are the intended mechanism. The scale should be quite 
> > > manageable.
> > >
> > > Again, i2 proposes VESA certificates provided to broadband access 
> > > infrastructure providers (not ISPs necessarily).
> ensuring the 
> > > emergency network has confidence in the source of the location 
> > > information. It is the same concern as exists with respect to 
> > > location-by-value.
> > >
> > > I believe a LIS will always be in the same jurisdiction 
> as the VPC - 
> > > and the VPC will always be in the same jurisdiction as 
> the emergency 
> > > call center. The VSP may be cross-jurisdictional to these 
> entities. 
> > > While this doesn't impact the protocols themselves, I believe it 
> > > will be structured this way to maintain jurisdictional integrity.
> > >
> > > Cheers,
> > > Martin
> > >
> > > > > > To amplify: The fundamental problem is that, in 
> general, a LIS
> > > can't
> > > > > This is a reasonable indication of how to 
> authenticate emergency
> > > > entities
> > > > > Authentication of a LIS is, understandably, a 
> different class of
> > > > problem.

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Sep 2006 11:14:09 -0400

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Sep 2006 11:17:54 -0400

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 10:18:01 -0500

Sea below...

Cheers,
Martin

> I don't understand what the advantage of this should be.
[[Martin Dawson] ] The advantage is in privacy. For some it is hard, but
imagine that location is being conveyed in some protocol other than SIP
- perhaps to a web based application. Further, imagine there is no
facility for encryption in that conveyance protocol and the peer to peer
signaling between the device and the application server traverses an
arbitrary number of other nodes. Location by value exposes the location
along the transport path. Location by reference only exposes a reference
which contains no location specific information. Only the application is
authorized to dereference; none of the intervening nodes can do that.
> I don't understand this backward compatibility argument.
[[Martin Dawson] ] Because changes in specifications, even XML ones, can
introduce backward incompatibilities. The location reference is a simple
URL. There is no need for the location acquisition client software on
the device to be absolutely up to date in scenarios where it is
requesting a reference because it does not need to parse the location
object. The application needs to be able to because it is the actual
consumer of the location information. In many of these scenarios the
device and the conveyance protocol are merely the conduit for location
information. The less they need to be concerned (particularly at the
interface between them) with the details of the PIDF-LO the more robust
that conduit is.

> > for example, the retrieval of location updates during the period of
that
[[Martin Dawson] ] If you have understood my elaboration on the i2
architecture, perhaps you can see that there is no peer signaling
relationship between the VPC and the device. However, the VPC is
responsible for obtaining location updates. By delivering a reference to
the VPC it can obtain the updates directly. If it doesn't have this,
updates cannot be obtained.
> complexity(location-by-value)<complexity(location-by-reference).
[[Martin Dawson] ] As above, by removing the location value from the
conveyance, it is not exposed on the transmission path so leading to
scenarios where location by reference provides better privacy than
location by value.

> complexity(location-by-value)<<complexity(location-by-reference).
[[Martin Dawson] ] Things are quantified arbitrarily in these
discussions. The dereferencing mechanism, including the authentication
and authorization will become a commodity function. Establishing an SSL
connection can certainly be considered complex but that doesn't stop it
happening all the time.

> location signing being particularly useful.
[[Martin Dawson] ] If you are doing location by value, then it is of
critical significance to the PSAP operator community. They want to know
whether the PIDF-LO was constructed by a recognized entity (e.g.
Verizon) and whether it has been tampered with before it reached them.
Without such a mechanism, they cannot differentiate between such
location fixes and ones that the user just chose to make up - despite
being nowhere near the serving area of that PSAP. Without such a
differentiating mechanism they have no basis for establishing automated
policies for call treatment.
> other protocols but I don't see it being particularly useful.
[[Martin Dawson] ] They could be, but the temporal aspect is simpler
when the location is dereferenced instantaneously - which is a benefit.
> That's why we do standardization. We specify what information is being
[[Martin Dawson] ] But how does the generic client know what form of
location is required by the application? For example, does an emergency
call in a particular jurisdiction I'm visiting require the postal civic,
the jurisdictional civic, or a geodetic form? If the client provides the
reference to the application it can request the form it needs. This is
simpler so I cite it as a benefit.

> >> of the caller is mobile, and thus refresh of location when queried
by
> >> as I understand them today, but could be extended relatively easily
to
> >> I would appreciate your list of benefits.  I quick look in my
archive
> > did
> >> the LIS to control access to location for business purposes.  I
agree
> > that
> >> simply stating a negative is not a particularly useful approach
unless
> >>> who continue to raise the "business model benefit" and it's done
so
> > as
location-by-reference

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 10:37:12 -0500

Seymour below..

Cheers,
Martin

> Sent: Friday, 15 September 2006 12:20 AM
> To: Dawson, Martin
> Cc: Henning Schulzrinne; [email-masked]; Marc Linsner; Andrew Newton
[[Martin Dawson] ] Sure but that's enforcing a requirement on all future
application protocols in the absence of knowing what the constraints are
on all future application protocols. The reference provides an option.
I've said it a lot but just to be clear, I'm not suggesting location by
value isn't also an application protocol option. I liked the suggestion
somebody else made today of sending both in the context of the emergency
application.

>     to have Location Recipients needing a relationship with the
[[Martin Dawson] ] There does not need to be a relationship between the
location user and the LIS - as long as the LIS can evaluate the rights
policy provided by the device. As to charging - thphht - how about the
access network put a charge on the ability to get location by value
instead. Business models will sort themselves out. I know I won't want
to use an access provider that only lets me use a subset of third party
location applications. Just as I won't want to use an access provider
that only lets me use their VoIP service from their access. It will be a
differentiator for a competitor that doesn't apply that constraint. As
I've said a few times, if we get bogged down in trying to mould the
protocols around our preferred business models we'll certainly expend
unnecessary effort and possibly come up with a biased specification that
doesn't suit some other scenario which wasn't part of our assumption
suite.

> ability to convey a reference in these protocols anyway.
[[Martin Dawson] ] Most certainly you need to standardize the conveyance
- and for some of these protocols the quickest conveyance facility that
can be added may be using a reference. Apart from SIP - the other VoIP
protocols - H.323, MGCP, etc. many of which are deployed in closed
environments but which shouldn't be deprived of a standard facility such
as a LIS - don't really warrant investing more than the minimum effort
to add conveyance. Then, of course, there's HTTP transporting any number
of web application protocols that will want to provide the benefit of
user location. I'm looking forward to being able to press the "You are
here" button on Google Earth for example and actually see the location
as provided by my access network rather than a half-baked attempt to
reverse-geo my IP address. Finally there's TFP - that future protocol we
haven't even thought about yet. Oh yes, the V2 interface protocol in i2
is another conveyance protocol already defined - though it supports both
forms.

> >>> for example, the retrieval of location updates during the period
of
> updated location then he can do so.
[[Martin Dawson] ] see elaboration on i2 for an example of why that
isn't always possible.
> >>> Losing privacy of location information means losing the
information
> What is temporal integrity?
[[Martin Dawson] ] The notion that the location provided actually
applies to the target *now* rather than it being something that they
obtained from the access, say, six months ago.

> >>> Jurisdictional/Emergency civic, Geodetic, and arbitrary other
forms

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 10:41:56 -0500

C below.

Cheers,
Martin

> Cc: 'GEOPRIV'; Thomson, Martin; 'Henning Schulzrinne'
> > I think if you give your location by value to anyone, including a
PSAP,
> they
[[Martin Dawson] ] Though the target provides the LIS with the rights
list so, by proxy, it is the target also doing the authorization.
> > So, it's kind of a ticket, but we aren't proposing to use
authentication
> > possession of the reference is the same as possession of the
location.
[[Martin Dawson] ] No, because you have to have the ticket and be
allowed to use it.

> Since this is hard to enforce I would very much prefer
location-by-value.
[[Martin Dawson] ] Well you can certainly use location by value. I would
like the option of using location by reference as well. And controlling
the authorization at the LIS is presumably no more complex than is being
proposed for controlling the access at a presence server. Lots of scope
for re-use there.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 17:53:04 +0200

Based on what I read from the mailing list discussion so far I think 
that there are architectural problems with the NENA architecture. So 
far, I thought that it is very much aligned with the IETF work but it 
seems that I am wrong.

The design goal rather seems to demand a need to establish relationships 
between the access provider and the consumer of location information 
(based on the authorization and security infrastructure).

This also seems to be the reason for requiring location-by-reference 
since location-by-value does not provide this functionality.

I am disappointed.

Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 11:04:22 -0500

I don't get the hang up on business models. Nor the judgmental attitude.
Nevertheless, it's irrelevant.

The purpose is to support emergency calling for VoIP as soon as
possible. 6000 separately managed and funded PSAPs do not change over
night - they don't even change over a decade.

Presumably we'd all like to see the plug being pulled on the switch
circuit networks as soon as possible, get the global population onto the
richer platform of the Internet. Currently E911 is a barrier to VoIP
adoption - it's also the case that using VoIP currently means people
suffer a degradation in their ability to reliably receive emergency
support. Note that i2 also applies globally and there are participants
from global operators in ESIF. Getting i2 implemented asap is very
important and, by providing the impetus to put LIS infrastructure in
place in the access networks, it also lays the groundwork for the
eventual migration to i3/ECRIT. It's a good thing. 

If you discard the conspiracy theories, you should be able to take i2 at
face value and see that the value of location by reference in this
context has nothing to do with business models. I'm certainly happy to
spend some time going over the architecture and explaining its origins
and imperatives if you like Hannes. Or getting James W to :)

Cheers,
Martin

> Cc: Henning Schulzrinne; Brian Rosen; GEOPRIV
> >>> PSAP, they
> >>> authentication of

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 18:01:16 +0200

I apologize for the 'broken business model' term.
I got a little bit disappointed in this discussion ...

Andrew Newton schrieb:
> Hannes Tschofenig wrote:
>> If NENA is going along this path then I am seriously concerned about 
>> the complexity they create just to support some broken business models.
>>
> "broken" business models need to be toned down.  Last I checked, 
> communism has been nothing but a total failure, and we all need to get 
> over the fact that at some point, some where, no matter if we work in a 
> commercial research institution or academia or respond to email in 
> between bouts of shouting at C++ compilers, somebody has to earn revenue 
> and make a profit.
> 
> system that has as a prerequisite universal access also serving more 
> closed environments for commercial purposes, but I think it should be 
> clear to all of us that mortgages must be paid and food must be purchased.
> 
> -andy
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 11:17:53 -0500

Well I'm sure it would be nice to wave a magic wand and have every PSAP
transformed into a shiny new VoIP end point bristling with multimedia
dispatch and monitoring facilities. Reality is that we won't get
emergency services for VoIP for decades if we wait for that to happen
with all of them.

We could have sat around feeling disappointed or, as a few did, put a
lot of hard work into specifying how the more dynamic IP side of the
equation can adapt to the legacy interfaces already in place and
demonstrate that VoIP really can be viable in this environment. I'm
sorry that it disappoints you but we did the best we could.

Cheers,
Martin

> Sent: Friday, 15 September 2006 1:53 AM
> To: Dawson, Martin
> Cc: Marc Linsner; Brian Rosen; Thomson, Martin; Henning Schulzrinne;
> GEOPRIV

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 11:33:20 -0500

Well James asked for an example of location being used at the device.
You jumped to interpreting it as a proposal to deprecate... something...
all these other protocols provided an analog to. I assumed you meant the
fact that they transfer data and that this was equivalent to location
value. So you were inferring he was proposing deprecating location by
value - as far as I could see. And I do want to be clear that I
certainly want location by value retained.

Sad to say, but I agree with you :) It's easy to think of examples of
the location being consumed at the device. A navigation application that
has all the intelligence and map data on the device, just wants the
location from the network and that's all.

I don't know where your world stopped but mine's moving to an AJAX model
with network based services and dopey end points...

Cheers,
Martin 

> Sent: Friday, 15 September 2006 1:14 AM
> To: Dawson, Martin
> Cc: [email-masked]
> > > > > > it's done so as some kind of anti-benefit statement
presumably
> > > > > > > years of this discussion is the business requirement of
not
> > > > letting
> > > > > > > > is now time for us to determine how we should move
forward
> > > > > > > > another element is of limited scope as
self-determination
> > > > methods
--------------------------------------------------------------
> > > > > > ----------------------------------
--------------------------------------------------------------
> > > > > > ----------------------------------
> > > > > > [mf2]
> > > > >
contain

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 11:33:55 -0500

Gosh... compelling. Thanks for that. Bye then.

> Sent: Friday, 15 September 2006 1:18 AM
> To: Dawson, Martin
> Cc: 'GEOPRIV'
access
> > > > > > Like you say, thousands of LISes might exist, with far
greater
> > > > > diversity.
> > > > ----------
> > > > ----------
contain

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Sep 2006 12:47:23 -0400

Well, the i3 call flow is the basic IETF call flow:
* Endpoint gets location, puts it on emergency call with SIP conveyance
* Mapping is via LoST to a SIP URI
* Routing is by normal SIP means

NENA i3 fully endorses the IETF emergency call work.  The actual NENA i3
effort is more concerned with how calls are handled within the domain of the
"Emergency Services IP Network".

We do expect that there may be one or more "Emergency Services Routing
Proxies" between the border of the user's domain and the PSAP (that is,
within the ESInet).  Some of them might do further, more fine grained, LoST
based routing.

Brian

> Sent: Thursday, September 14, 2006 10:19 AM
> To: Dawson, Martin

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Sep 2006 12:51:43 -0400

> rather the LIS. Hence, it is the LIS that authorizes and not the Target.
No, the reference is to the location of the target.  The ruleset is that of
the target.  The reference is handed out by the target (you normally get the
reference from the LCP, right?  The LIS gives the reference to the target,
the target gives it to some other entity).  The LIS creates the reference,
but that does not change the privacy policies associated with it.
As you have agreed, you hand out the reference the same way (and as
carefully) as you would the value.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Sep 2006 13:02:22 -0400

Also, this architecture does not preclude the use of 'legacy' PSAPs via 
gateways. The gateway would insert location information into the right 
legacy database or provide V3-style interfaces. In general, I think the 
right system architecture is to design for where you want to go, not for 
backward compatibility, and then make sure there are gateways during the 
transition. Such gateways can be relatively simple if you are bridging 
single PSAPs, rather than whole systems. The complexity of i2 comes 
about because you not only have to support legacy PSAPs, but have to 
support legacy callers as well. This is particularly important since we 
want this architecture to be usable beyond the US, and most non-US 
systems don't look like the existing US environment.

H.323 tried the former approach, trying to look like ISDN on packets.

Thus, none of the transition argument in any way requires or favors LbyR.

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 12:37:50 -0500

Henning - i2 is a *migratory* architecture. It's designed to be backward
compatible. The i2 architecture doesn't actually involve legacy callers
- so I don't know why you say that. The complexity comes about because
we are binding VoIP onto essentially two existing interfaces - the,
usually ISUP, selective router trunks and the E2 interface from the
ALIs. Make changes beyond that and it means you can't deliver E911 for
VoIP. And you'll have to elaborate more on exactly what is inserting
what where; without the hand waving? We're talking about a future
location, not the one at call establishment, so what are you saying the
gateway is doing?

To the extent that H.323 says anything about the design requirements of
i2 (very little) you've got to agree it worked and got VoIP going -
which is what we're trying to achieve on a broader scale with i2.

Thus... huh? I missed something or there's a distinct non sequitur
leading up to the "thus". I've cited an example of a situation that
*requires* the reference. It's like Marc saying I only like it because
it supports the "argument" whereas I provided it as a genuine example.
Apparently the response is that any example provided is not valid
because there must be something wrong if it doesn't work using
by-value... there's the argument by tautology.

Cheers,
Martin

> Sent: Friday, 15 September 2006 3:02 AM
> To: Brian Rosen
> Cc: 'GEOPRIV'
> > effort is more concerned with how calls are handled within the
domain of
> > within the ESInet).  Some of them might do further, more fine
grained,
> LoST

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Sep 2006 14:08:41 -0400

Martin

I recently had the occasion to discuss with several wireless carriers and
PSAP people how location update is actually used.

As you know, initial routing today is almost always based on cell/sector.
What actually happens is that some time after the call is answered, the call
taker requests a location update.  The actual location of the caller is
returned.

In nearly every case, that is ALL there is, one update.  Sometimes the call
taker asks too early, and they have to do the query once more.

Use LbyV.  Send a request back to the endpoint, let it ask the LIS, and
return the answer.  It will work fine.  IT WILL WORK FINE IF DHCP IS THE
ONLY LCP THE ACCESS NETWORK IMPLEMENTS!!!!!

If the call taker requeries more than once, do it again.  It's MANUAL.  If
it's manual, there is no problem in any system I can think of to go back to
the endpoint and let it get you the new location.

Brian

> Sent: Thursday, September 14, 2006 10:38 AM
> To: Hannes Tschofenig

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 14 Sep 2006 16:15:59 -0500

Marc,

It was you that drag the "actual" requirement in the equation.
I merely pointed out that location by value is but one possible solution
to that problem. You are continually arguing from the premise that
location by value is a requirement, I am indicating that it is no more
so than location by reference.

Cheers
James

> advocating
an
such
promulgated.
R
wireless
appropriate
contain

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 14 Sep 2006 16:24:51 -0500

Marc,

I am suggesting that is what the host wants and that providing location
by value is one way to achieve that. That does not make providing
location by value a requirement to solve the overall problem, providing
by reference achieves the same result. For you to argue that by value is
a requirement and by reference is not is absurd and biased.

Cheers
James

presumably
not
forward
self-determination
contain

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 14 Sep 2006 16:53:48 -0500

Well firstly DHCP is not okay if you are using it to represent a
geodetic location, see previous thread, but I am sure that the
supporters of that specification will come up with a suitable update
that will correct the flaw and clarify the intent.

Secondly, please describe what you mean by manually as it has a huge
bearing on any solution you are suggesting.

Cheers
James

> Sent: Friday, 15 September 2006 4:09 AM
> To: Dawson, Martin; 'Hannes Tschofenig'
> What actually happens is that some time after the call is answered,
the
> call
> it's manual, there is no problem in any system I can think of to go
back
> > > > presumably an end-to-end IP location call can be quite
sophisticated
> > > > In i2, the VPC queries the LIS. The VPC is a hub for all the
PSAPs
> > and
> > > > PSAPs are a hub for all the police and etc. Each hub has to have
its
> > own
certificates
> > > > Authenticating the LIS identity is actually a separate issue.
Again,
> > i2
> > > > location integrity - ensuring the emergency network has
confidence
> > in
> > > > the source of the location information. It is the same concern
as
> > exists
> > > > I believe a LIS will always be in the same jurisdiction as the
VPC -
> > > >> I do not buy the physical presence argument at all.  For
example, I
> > > >> I think it may be possible to get credentials issued to PSAPs
in
> > North
> > > >> credentials is MUCH more problematic.  Getting credentials in
other
> > > >> not imply that privacy and integrity protection is not
desirable,
> > > >>>> To amplify: The fundamental problem is that, in general, a
LIS
> > > > can't
> > > >>>> know all the legitimate recipients of location information
and
> > the
> > > >>>> PSAPs (and other associated entities, such as first
responders)
> > > >>>> thousands of entities within a particular jurisdiction. Both
sets
internet
> > > >>> Because both have a link to the physical location, then there
is a
> > > >>> In the US, NENA is looking at setting up a certificate
authority
hint
> > > > at.
> > > >>> This is a reasonable indication of how to authenticate
emergency
> > > >>> Authentication of a LIS is, understandably, a different class
of

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 17:01:47 -0500

I have the opportunity to talk to cellular operators pretty much every
day and there's no ambiguity that the ability to get a location update
*at any time* and *as many times* as possible is a strict requirement.
It's not just about getting the more accurate location the second time
around but, certainly, where GPS is involved that is absolutely the
case. (I'm just boggling at the prospect of a DHCP server providing
assistance data for a GPS fix... thphhht... OK, I'm better now). The
requirement is there because in some emergency situations the ability to
track the caller is vital to a successful outcome (the classic hostage
in a trunk scenario; though the reality may be more prosaic). The fact
that it's not needed in the majority of cases hardly seems important -
unless you're advocating a deterioration of the quality of emergency
service as an inevitable consequence of the switch of telephony to IP.

In any case - what are you actually talking about? If you are in a
topology where it is possible to get a location update request back to
the device, then by all means use location by value - whether you need
to do it once or multiple time. It's got zip to do with whether it's
DHCP or not so I don't even know what that comment is doing in there.

How do you propose to get this request back to the terminal for the many
years in which we are going to be using i2?

Cheers,
Martin

> Cc: Thomson, Martin; 'Henning Schulzrinne'; 'GEOPRIV'
the
back
sophisticated
PSAPs
its
certificates
Again,
confidence
as
VPC -
example, I
in
other
desirable,
LIS
and
responders)
sets
internet
is a
authority
hint
emergency
of

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Sep 2006 19:49:26 -0400

James,

I guess we simply disagree.  I believe having the data is vastly superior to
holding a pointer to where it might be had.

-Marc- 

> Sent: Thursday, September 14, 2006 5:25 PM
> To: Marc Linsner; Dawson, Martin
> Cc: [email-masked]
> I am suggesting that is what the host wants and that 
> providing location by value is one way to achieve that. That 
> does not make providing location by value a requirement to 
> solve the overall problem, providing by reference achieves 
> the same result. For you to argue that by value is a 
> requirement and by reference is not is absurd and biased.
> 
> Cheers
> James
> 
> 
> > the target/host, only the computational result derived from 
> said data.
> > I'm
> > simply suggesting that is true of many applications, but 
> attempting to 
> > point out how absurd this idea is since the world has moved to 
> > intelligent
> end
> > points.
> > 
> > -Marc-
> > 
> > 
> value be 
> > > > location by reference.  I suggest you provide 
> convincing arguments
> > > towards
> > > > > Carrying the requirement argument forward, it is 
> seldom if ever
> a
> > > > > > the L by R justification.  We can take it off the 
> table if you
> > > wish.
> > > > > >
> > > > > > >
> > > > > > > > One thing I continue to look for when L by R 
> solutions are
> > > > > discussed
> > > > > > > is
> > > > > > > > the
> > > > > > > > 	c) I see no reason why any mechanism to 
> support wireless
> > > > > > > location
> > > > > > > > > To that end, I offer the following 
> inexhaustive list of
> > > > > > > observations
> > > > > > > > > on this
> > > > > > > > > topic:
> > > > > > > > >
> > > > > > > > > 2) Location measurement and determination 
> (sighting) of
> a
> > > > > > > target by
> > > > > > > > > authentication that could cause the failure 
> of emergency
> > > call

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 14 Sep 2006 18:52:11 -0500

Perhaps in some circumstances it is. But it is still a solution and not
a requirement.

> Sent: Friday, 15 September 2006 9:49 AM
> To: Winterbottom, James; Dawson, Martin
> Cc: [email-masked]
> I guess we simply disagree.  I believe having the data is vastly
superior
> > > > > The bottom line is, this community agreed to the
requirement(s)
> > that
> > > > an
> > > > > end
> > > > > host needs to know it's location by value, but hasn't yet
agreed
> > > > > > Perhaps you can state a requirement where the end point
wishes
> > > > > > > > protocol that provides useful functions to those that
want
> > > > > > > > > know the location.  Notwithstanding personal opinion
on
> > > > > > this, this
> > > > > > > > > requirement obviously cannot be accomplished by
current
> > > > > > mechanisms.
> > > > > > > > > normally motivate Internet engineers, lack of
bandwidth
> > > > > > > > isn't normally
> > > > > > > > > > html), we have not truly come to consensus on
location
> > by
> > > > > > > > reference
> > > > > > > > > > within this working group.  The GEOPRIV working
group
> > > > > > has been
> > > > > > > > > > to convey its location.  It is more efficient
because
> > > > > > the target
> > > > > > > > > > topic, I welcome comments regarding the above as
well
> > > > > > as further
contain

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Sep 2006 20:09:01 -0400

> years in which we are going to be using i2?

SUBSCRIBE, say? If you really felt like it, defining a new SIP method  
would also be possible and relatively easy.

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 19:43:39 -0500

At the risk of being repetitive, a PSAP wouldn't know how to do a
subscribe. It gets a call on a CAMA trunk... modifying the CAMA
specification to push the semantic equivalent of a SIP subscribe back
down the call path is just the first nonsensical step to proceed with
that suggestion. The PSAP also knows how to do an ALI request, generally
using the PSAP-ALI message (PAM) protocol which the ALI can convert into
an ESPOSREQ over the E2 interface. We're already out of the call path
here...

So where is this subscribe going to come from and how is it reaching the
terminal? And since i2 has been specified to not have a bias to a
particular VoIP protocol (minimum impact being they only need to provide
an initial location - by value or by reference or work in a topology
where a proxy does that on their behalf) we would also need to modify
every other VoIP protocol (Skype etc) to provide for a call path
location query function. It's easy to say it's easy to do Henning. I
haven't seen anything be easy or fast to ratify in these forums.

Cheers,
Martin

> Sent: Friday, 15 September 2006 10:09 AM
> To: Dawson, Martin
> Cc: GEOPRIV

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Sep 2006 21:07:13 -0400

What I/m saying is that in current systems, there is nothing that is an
automatic (machine generated) location update.  It's done by a human
pressing a button on a computer app (Mark says in his PSAP, the system does
ONE update 12-15 seconds into the call).  When you "track", it's not some
polling automaton that displays a moving icon on a desk, it's a human
pushing the button when he wants to see where the guy is now.  And it that
is the worst case; the normal case is ONE (count them) update.

If that is the scenario, then there is no reason you can't make a complete
round trip from the PSAP to the VPC, to the VSP to the endpoint to the LIS
and back again.  Short circuiting the connection so it's VPC to LIS doesn't
get you anything.  There are a small number of calls, and a small number of
updates, and you don't need to optimize it.

The DHCP thought was merely that this process happens so infrequently that
actually having the endpoint requery its DHCP server (if that was what the
LCP was) to get a location update is eminently practical.  

So, in detail:
The VPC requests an update from the endpoint (all the current VPCs have the
SIP call) by ReInvite.  The endpoint reruns an LCP query to the LIS, and
responds with location in the 200 OK.

Brian

> Sent: Thursday, September 14, 2006 6:02 PM
> To: Brian Rosen; Hannes Tschofenig
> Cc: Thomson, Martin; Henning Schulzrinne; GEOPRIV

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Sep 2006 20:48:59 -0500

Why is there any relevance to whether the PSAP request is initiated by
the CPE automatically or by an operator clicking a button on a CPE
screen. It seems about as relevant as the DHCP point.

And a VPC does not have a call. If you're referring to a combo proxy and
VPC, then you are relying on some proprietary functionality to get the
request from the VPC component supporting the E2 interface and back to
the proxy component. You are throwing up your hands and saying - well do
something proprietary then rather then use something eminently suitable
like location by reference.

Now, is the service bureau proxy that you're really referring to going
to establish the subscribe directly to the device itself, or is it going
to have to go back via the VoIP call server? If it does it directly to
the device then you've just introduced all the concerns that you had
over third parties being able to get location via a reference. How is
the device supposed to know who this proxy is? If it goes back via the
VSP call server, then you're now also asking the VSP to support some,
currently unspecified, additional functionality for this update process.
And what if the VSP is Skype? They also need to invent a location query
protocol on top of everything else?

You were involved in the i2 WG Brian, you know we discussed all these
sorts of options and dismissed them because we were looking for the
minimal impact on the various participants in VoIP (in the real world).
It seems somewhat disingenuous in another forum to be pushing
impractical solutions now that i2 is published and in the process of
implementation.

It's just occurred to me that the reference to DHCP may have been
somewhat Freudian. Are all of these gymnastics driven by the prospect
that DHCP doesn't support a location reference mechanism?

Cheers,
Martin

> Sent: Friday, 15 September 2006 11:07 AM
> get you anything.  There are a small number of calls, and a small
number
> The VPC requests an update from the endpoint (all the current VPCs
have
> > > I recently had the occasion to discuss with several wireless
carriers
> > > taker requests a location update.  The actual location of the
caller
> > is
> > > returned.
> > >
> > > In nearly every case, that is ALL there is, one update.  Sometimes
the
> > > Use LbyV.  Send a request back to the endpoint, let it ask the
LIS,
> > and
> > > return the answer.  It will work fine.  IT WILL WORK FINE IF DHCP
IS
> > THE
> > > If the call taker requeries more than once, do it again.  It's
MANUAL.
> > If
> > > > PSAP on primarily CAMA trunks. PSAPs only have the ability to
query
> > for
> > > > location through an ALI - you can't swim back upstream through
all
> > that
> > > > legacy interconnect to initiate a request for location
conveyance.
> > > > i3 may support call-associated conveyance for location updates
but
> > it is
> > > > to become mainstream by having full E911 support in the
migratory
> > period
> > > > am particularly keen to ensure that the IETF doesn't throw a
spanner
> > > > > I don't know the details of the i3 infrastructure but this
seems
> > > > pretty
> > > > > complicated. I wonder why NENA does not go for a simple
solution,
> > > > namely:
ECRIT
> > -
> > > > > > authorization architecture - and does in the legacy
emergency
> > > > network.
the
> > VPC -
> > > > and
> > > > > > the VPC will always be in the same jurisdiction as the
emergency
> > > > call
> > > > > > center. The VSP may be cross-jurisdictional to these
entities.
> > While
> > > > > > this doesn't impact the protocols themselves, I believe it
will
> > > > > >> a mutual aid fire company from out of area needing to
access
to
> > > > > >>>> thousands of entities within a particular jurisdiction.
Both
greater

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Sep 2006 08:00:24 -0400

> screen. It seems about as relevant as the DHCP point.
At first blush, it seems that there is value in making a direct path from
the LIS to the VPC (where the VPC is the watcher), rather than looping
through the endpoint.  However, when you look at the actual use case, I
think there is little value.  The reason is that the frequency of update is
very low, so low that any optimization seems pretty worthless.

The FIRST location operation is MORE complex (the endpoint gets the
reference from the LCP, sends it to the VPC, the VPC exchanges it for
location with the LIS).  The second operation would, if there was a direct
connection, be more efficient (VPC to LIS).  Average them for two dips and
it's a wash.  But 2 dips IS the usual case.

They both work.  There is no functionality difference except that in the
LbyR you need an extra interface and path.

i2 is a lousy use case for LbyR

> like location by reference.
I'm saying that every VPC I know of has the proxy.  If you like, suggest an
update interface between the VPC and the proxy in the i2.5 effort, I'll
support that.  All of the VPC interfaces are NENA developed.

> protocol on top of everything else?
I'm asking that the VPC reInvite back towards the endpoint, which means it
goes through the VSP (this means the VPC proxy acts as a B2BUA, but most of
them do this anyway for other reasons).  The VSP does not need to support
anything but reInvite.

> impractical solutions now that i2 is published and in the process of
Mobility was not well thought out.  ALL we did is to decline to do anything
that would preclude supporting mobility.  The word "mobile" as used in this
context appears once in the i2 document, describing one use of the V3
interface.  My solution is eminently practical.

> that DHCP doesn't support a location reference mechanism?
No, it's just that you would think using DHCP as an LCP for a mobile device
is ludicrous.  In this use case, it is not.  You might have other use cases
where it would be, but not this one.

I'm happy to support a location reference mechanism for DHCP if we decide
that is a good thing.

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Sep 2006 09:42:52 -0500

Feel free to take the suggestion to i2.5; it's a noble cause and I'm
sure the ensuing discussion will be interesting. I believe your proposal
is eminently complex, fraught with implementation difficulties, and will
meet with considerable resistance from both VSPs and the vendors of soft
switch products. I think you'd be better off waiting for i3 where the
peer signaling relationship between the PSAP and the terminal can be
capitalized on.

In the mean time, i2 is in the process of implementation so having the
IETF not helping will only likely make the IETF not relevant to its
development which will ultimately make the ability of the IETF to
contribute to further evolution that much more difficult. A great pity.
The location reference mechanism will need to be supported, by wireless
LIS operators at least, one way or the other.

Cheers,
Martin

> Sent: Friday, 15 September 2006 10:00 PM
> think there is little value.  The reason is that the frequency of
update
> I'm saying that every VPC I know of has the proxy.  If you like,
suggest
> goes through the VSP (this means the VPC proxy acts as a B2BUA, but
most

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Sep 2006 11:07:48 -0400

Martin,

Why did i2 promise LbyR functionality prior to IETF review, if in fact NENA
was dependent on IETF for such a mechanism? 

Promises YOU made in i2 does not force consensus in GeoPriv.

Btw, I do believe there is middle ground on LbyR!

-marc-

> Sent: Friday, September 15, 2006 10:43 AM
> Cc: GEOPRIV; Thomson, Martin; Henning Schulzrinne
> Feel free to take the suggestion to i2.5; it's a noble cause 
> and I'm sure the ensuing discussion will be interesting. I 
> believe your proposal is eminently complex, fraught with 
> implementation difficulties, and will meet with considerable 
> resistance from both VSPs and the vendors of soft switch 
> products. I think you'd be better off waiting for i3 where 
> the peer signaling relationship between the PSAP and the 
> terminal can be capitalized on.
> 
> In the mean time, i2 is in the process of implementation so 
> having the IETF not helping will only likely make the IETF 
> not relevant to its development which will ultimately make 
> the ability of the IETF to contribute to further evolution 
> that much more difficult. A great pity.
> The location reference mechanism will need to be supported, 
> by wireless LIS operators at least, one way or the other.
> 
> Cheers,
> Martin
> 
> > > Why is there any relevance to whether the PSAP request is 
> initiated
> by
> > through the endpoint.  However, when you look at the actual 
> use case,
> I
> > connection, be more efficient (VPC to LIS).  Average them 
> for two dips
> and
> > > And a VPC does not have a call. If you're referring to a 
> combo proxy
> and
> > > request from the VPC component supporting the E2 
> interface and back
> to
> > > to have to go back via the VoIP call server? If it does 
> it directly
> to
> > Mobility was not well thought out.  ALL we did is to decline to do 
> > anything that would preclude supporting mobility.  The word 
> "mobile" 
> > as used in this context appears once in the i2 document, describing 
> > one use of the V3 interface.  My solution is eminently practical.
> > 
> > >
> > No, it's just that you would think using DHCP as an LCP for 
> a mobile 
> > device is ludicrous.  In this use case, it is not.  You might have 
> > other use cases where it would be, but not this one.
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Sep 2006 17:13:37 +0200

Hi Martin

Dawson, Martin schrieb:
>>> that i2 d			oesn't support mobility. It would have been useful to have

I am not a favor of compiling requirements that could eventually we 
useful in a future protocol that does have certain properties (e.g., 
lack of end-to-end security).

> interface between them) with the details of the PIDF-LO the more robust

This is indeed an interesting requirement.

> updates cannot be obtained.

I would have to read through the i3 documents to better understand why 
this location update is at all needed. (Don't tell me 'in order to 
obtain the most recent location information about the Target'.)

> scenarios where location by reference provides better privacy than

That's not true.

Let us consider the case where location-by-reference is used without 
authorization policies.

In this case the two security mechanisms are equivalent. You can apply 
end-to-end security to both in order to prevent intermediaries to obtain 
  your location. If we consider the emergency case then this is of 
limited value since intermedaries need to have the location anyway to 
perform location-by-based routing.

Using end-to-end security is almost as good as location-by-reference 
with authorization policies if we ignore the retargeting problem.

The usage of the authorization policies, however, introduces a 
significant problem with regard to the infrastructure required to make 
the policies to work.

Consider the following example: I want to convey my location to a couple 
of friends. In my case I would just send them the location secured using 
end-to-end security.

In your case, I would obtain a reference, upload policies for Alice, Bob 
and Trudy to the LIS.

Now, the problem starts when they want to retrieve location information 
since they have to authenticate to the LIS in order to use 
identity-based authorization. How would they authenticate to the LIS? 
They don't know the LIS in the access network and the likely hood that 
they share credentials with them is for sure zero.

> connection can certainly be considered complex but that doesn't stop it

The complexity is in the authorization and key management part not in 
the performance of the TLS handshake. See my example from above.

> policies for call treatment.

We describe this aspect in the draft-tschofenig-geopriv-l7-lcp-ps-02.txt 
  document. My conclusion from the discussion so far was that it is far 
more valuable to provide authentication of the emergency call with 
regard to tackle malice.

> simpler so I cite it as a benefit.

I never say these differentiations as being useful. To me this is academic.

There is only one place where the ambulance should go: To the place 
where I am at the moment (lying on the ground).

You might want to start a separate thread to discuss this in more detail.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Sep 2006 17:14:18 +0200

Hi Martin

please find my comments below:

> somebody else made today of sending both in the context of the emergency

For me this is not really a big deal since you have to investigate the 
properties of each using protocol anyway. So far, we haven't had too may 
  proposals for using protocols anyway.

> doesn't suit some other scenario which wasn't part of our assumption

Andy told me not to discuss business models anymore.
He slapped me in front of the Geopriv court.

> is another conveyance protocol already defined - though it supports both

I am sure it is nice to use our work in various protocols. I do, 
however, believe (based on my past Geopriv experience) that some amount 
of analysis is required for each of these using protocols. At the end, I 
am not sure whether there is the potential to save some time in 
standardization when it comes to location-by-value vs. 
location-by-reference.

> obtained from the access, say, six months ago.

Got it.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Sep 2006 17:14:38 +0200

Hi Martin,

I am referring to the emergency caller's end host. I see the case where 
the end host does not support some of the extensions we are working on.

On the other hand: In ECRIT we are not talking about complex end host 
software updates.

The problem is going to be the following: Industry spends time to work 
on emergency service relates updates now without thinking about 
providing additional functionality at the end host. This has a number of 
problems as we discussed it in ECRIT. A solution with end host support 
is superior to a solution where only the network does the work.

Hence, I hope that the industry actually decides to put additional 
effort into end host updates onces they did the initial step.
We should very much encourage them to focus on the end host rather than 
given them incentive to get away with a 80% solution.

I certainly have to read through the i3 documents.

Ciao
Hannes

Dawson, Martin schrieb:
>> Dawson, Martin schrieb

---

From: Andrew Newton <[email-masked]>
Date: Fri, 15 Sep 2006 11:32:20 -0400

> Btw, I do believe there is middle ground on LbyR!

I do believe it would be interesting to hear your proposal.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Sep 2006 19:04:49 +0200

Hi Andy

I guess Marc refers to the proposal we discussed in the Geopriv-L7 
design team where a purely SIP-based mechanisms was used.

Here is what I recall:

* The Target discovers the LIS (which is a presence server) using either 
a DHCP option or the reverse DNS lookup.

* The Target registers at the LIS to request a URI. The SIP REGISTER 
triggers a 200 OK from the LIS with a URI similar to the one obtained 
from a conference (randomize username part). Let us call this returned 
URI geopriv-URI.

The Target might, for example, do the following:

    *   The Target subscribes to itself to obtain its own location
        information.

    *   It takes location information and queries the LoST

    *   The Target updates the subscription to the geopriv-URI with
        a location filter set to the service boundary previously
        obtained.

    *   If the Target moves outside a certain area, indicated by the
        location filter, then it will receive a notification.  The
        Target can re-query LoST to obtain a new service boundary
        in order to update the location filter.

Alternatively, the Target might just send the geopriv-URI to a Location 
Recipient. The Location Recipient uses a SUBSCRIBE whereby there are no 
authorization policies at the LIS to perform access control (since I 
think that this is a really bad idea). If the security of intermediaries 
is a problem then the Target would use end-to-end encryption to ensure 
that only the intended recipient is able to resolve the reference. For 
emergency services this is a bad idea anyway. For emergency services I 
would just use the location-by-value anyway but maybe there are some 
scenarios where this would be useful...

Ciao
Hannes

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Sep 2006 14:09:58 -0400

Andy,

You do understand it's Friday!

> I do believe it would be interesting to hear your proposal.

1) After gleaning thousands of diatribes on the benefits of LbyR, it is MY
interpretation (note IMO) that this community can only agree on one benefit,
the business model.  All other cited benefits, be it bandwidth, out-of-band,
privacy, security, veracity, etc., etc. have been deemed either
not-able-to-achieve or on-parity with LbyV.  So, unless further benefits can
be discovered, this community must decide if moving forward on the basis of
the single benefit is worthy (which, btw, I'm not opposed to as long as it
stated as the reason).

2) Proponents of LbyR continually 'attach' LbyR to various other work, NENA
i2, SIP Location Conveyance, L7 LCP, and then cite such as reasons to move
forward.  Such marketing in an engineering organization is
counterproductive.

3) With regards to LCP, James W. asserts that LbyR is on parity with LbyV,
hence we should move forward with it.  LbyV LCI solves one requirement:
"Advise an end point of it's location" PLUS all identified security risks.
Withholding opinion and all things considered, expending energy in
duplicative mechanisms isn't attractive.

5) Jon Peterson graciously brought us out of our myopic viewpoints when he
reminded us that we already support LbyR, it's called PRESENCE.

6) Brian suggested the LIS simply (pun intended) do PRESENCE.  It was met
with, 'What, my LIS run a SIP stack are you crazy???'  Ignoring that my UA
must run a HELD stack with the proposed alternative!

7) So, I suggest we investigate ways for existing mechanisms, PRESENCE, to
solve the ONE known impetus to move forward, the business model.

Which brings up several questions (I ask because I don't know):

A) Can my AOR presence service subscribe to the access provider presence
service to cascade the pidf-lo information?  (solves the referral
'requirement'?)

B) Can presence work where application presence (all but pidf-lo) is
delivered by the AOR server and location presence (pidf-lo) is delivered by
pres:[email-masked]?  In other words, can/will the
world live passing out 2 URIs for presence?

C) Is it safe to assume the access provider presence service will support
uploading rulesets via xcap?

I'm sure those smarter than I in presence will add to/take away from this
list.

TGIF

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Fri, 15 Sep 2006 16:59:59 -0400

> You do understand it's Friday!

Is that the reason you omitted point 4?

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Sep 2006 17:13:13 -0400

ghosts 

> Sent: Friday, September 15, 2006 5:00 PM
> To: Marc Linsner
> Cc: 'GEOPRIV'; Jonathan Rosenberg

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 15 Sep 2006 16:58:54 -0500

Marc,

You are a number of colleagues in this discussion were the ONLY
opponents to LbR in NENA and you lost that argument handsomely. At that
point it was made clear by the same league of individuals that they
would not let LbR fly in the IETF. So far I have only seen the same
misinformed FUD being thrown around, and the same people opposing it.
Please come back with something that is constructive.

Cheers
James

> Sent: Saturday, 16 September 2006 1:08 AM
> To: Dawson, Martin
> Cc: 'GEOPRIV'
> > > At first blush, it seems that there is value in making a direct
path
> > from
> > > location with the LIS).  The second operation would, if there was
a
> > direct
> > > They both work.  There is no functionality difference except that
in
> > > > VPC, then you are relying on some proprietary functionality to
get
> > > > to establish the subscribe directly to the device itself, or is
it
> > going
> > > > over third parties being able to get location via a reference.
How
> > is
> > > > the device supposed to know who this proxy is? If it goes back
via
> > > > And what if the VSP is Skype? They also need to invent a
location

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Sep 2006 18:21:30 -0400

Within NENA, LbyR was accepted due to the advertising, by a few, of what it
will deliver.  Such advertising is the true FUD.  This community has
reviewed that advertising and categorized it properly.  Sorry NENA, you were
told something that is not possible to deliver.

-Marc-

> Sent: Friday, September 15, 2006 5:59 PM
> You are a number of colleagues in this discussion were the 
> ONLY opponents to LbR in NENA and you lost that argument 
> handsomely. At that point it was made clear by the same 
> league of individuals that they would not let LbR fly in the 
> IETF. So far I have only seen the same misinformed FUD being 
> thrown around, and the same people opposing it.
> > Why did i2 promise LbyR functionality prior to IETF review, 
> if in fact 
> > NENA was dependent on IETF for such a mechanism?
> > 
> > > sure the ensuing discussion will be interesting. I believe your 
> > > proposal is eminently complex, fraught with implementation 
> > > difficulties, and will meet with considerable resistance 
> from both 
> > > VSPs and the vendors of soft switch products. I think you'd be 
> > > better off waiting for i3 where the peer signaling relationship 
> > > between the PSAP and the terminal can be capitalized on.
> > >
> > > In the mean time, i2 is in the process of implementation 
> so having 
> > > the IETF not helping will only likely make the IETF not 
> relevant to 
> > > its development which will ultimately make the ability of 
> the IETF 
> > > to contribute to further evolution that much more 
> difficult. A great 
> > > pity.
> > > The location reference mechanism will need to be supported, by 
> > > wireless LIS operators at least, one way or the other.
> > >
> > > Cheers,
> > > Martin
> > >
> > > > > the proxy component. You are throwing up your hands 
> and saying -
> > > well do
> > > > update interface between the VPC and the proxy in the 
> i2.5 effort,
> > > I'll
> > > > > Now, is the service bureau proxy that you're really 
> referring to
> > > going
> > > > > VSP call server, then you're now also asking the VSP 
> to support
> > > some,
> > > > > currently unspecified, additional functionality for 
> this update
> > > process.
> > > > I'm asking that the VPC reInvite back towards the 
> endpoint, which
> > > means it
> > > > them do this anyway for other reasons).  The VSP does 
> not need to
> > > support
> > > > anything but reInvite.
> > > >
> > > > >
> > > > > You were involved in the i2 WG Brian, you know we 
> discussed all
> > > these
> > > > > minimal impact on the various participants in VoIP 
> (in the real
> > > world).
> > > > I'm happy to support a location reference mechanism for 
> DHCP if we
> > > decide
> > > > that is a good thing.
> > > >
> > > > Brian
> > > >
> > >

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Sep 2006 20:11:58 -0500

Well, if you're prepared to acknowledge the "business" benefit - though
I think that's on overly specific label for the feature - then
wonderful. Let's go with that then.

I won't waste energy on the rest of the fluff. Sorry about raising i2 as
an example - God forbid the IETF be distracted by the real world.

Cheers,
Martin

> Sent: Saturday, 16 September 2006 4:10 AM
> To: 'Andrew Newton'
> Cc: 'GEOPRIV'
> the business model.  All other cited benefits, be it bandwidth,
out-of-
> band,
> not-able-to-achieve or on-parity with LbyV.  So, unless further
benefits
> can
> be discovered, this community must decide if moving forward on the
basis
> delivered by the AOR server and location presence (pidf-lo) is
delivered

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Sep 2006 20:20:46 -0500

Gee - with all the gleaning, deeming, and majority decisions you publish
- you must get memo's that I don't. Didn't I read there is no voting in
the IETF - must be secret polls? I expect that about 10% of this WG
actually reads these threads - maybe 9 people.

Cheers,
Martin

> Sent: Saturday, 16 September 2006 8:22 AM
> To: Winterbottom, James
> Cc: 'GEOPRIV'
> Within NENA, LbyR was accepted due to the advertising, by a few, of
what
> reviewed that advertising and categorized it properly.  Sorry NENA,
you
> were
> > > > > The FIRST location operation is MORE complex (the endpoint
gets
> > > > > > something proprietary then rather then use something
eminently
> > > > suitable
> > > > > goes through the VSP (this means the VPC proxy acts as a
B2BUA,
contain