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

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

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, 14 September 2006 3:53 AM
> To: Dawson, Martin; 'Marc Linsner'; 'Andrew Newton'; geopriv@ietf.org
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> 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
>
> > -----Original Message-----
> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > Sent: Wednesday, September 13, 2006 12:41 PM
> > To: Marc Linsner; Andrew Newton; geopriv@ietf.org
> > Subject: RE: [Geopriv] coming to terms on location by reference
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > Sent: Thursday, 14 September 2006 2:18 AM
> > > To: 'Andrew Newton'; geopriv@ietf.org
> > > Subject: RE: [Geopriv] coming to terms on location by reference
> > >
> > > 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-
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Andrew Newton [mailto:andy@hxr.us]
> > > > Sent: Tuesday, September 12, 2006 11:18 AM
> > > > To: geopriv@ietf.org
> > > > Subject: [Geopriv] coming to terms on location by reference
> > > >
> > > >
> > > > 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
> > > > Geopriv@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
------------------------------------------------------------------------
> --
> > ----------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original. Any unauthorized use of
> > this email is prohibited.
> >
------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
>

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 13 Sep 2006 18:26:53 -0500