Subject: RE: [Geopriv] WGLC for draft-ietf-geopriv-pidf-lo-01.txt

From: "Scott Keagy" <[email-masked]>
Date: Thu, 18 Mar 2004 08:53:50 -0800

James,

I'm not sure whether your response is already covering the following
suggestion raised at the joint meeting of the VoIP Operations Committee
and VoIP Tech Committee of the National Emergency Number Association
(NENA). This was a sidebar conversation and may not have been widely
noted.

[mostly location object issues with implications for emergency services
architecture toward the bottom]

Summary Requirement:
Field addition needed to civil and geo location formats: the time at
which the information was derived by an endpoint or network element.
Note that this is different from a timestamp on a packet that shows when
the location information was transported with an emergency call.

Example scenario:
A mobile device obtains a location in City A, and then gets on a plane
flight to a different city. Upon arrival at City B on the opposite side
of the country (or world), or even in transit during the flight, an
emergency call is placed from the device and there has been no update of
the location known by the device since prior to the flight. An emergency
call center might see the old location of City A, and a timestamp on the
packet that shows when the call was sent, when in fact the call
originated in City B at the time indicated in the packet timestamp. A
timestamp within the location information fields would provide a hint to
call-takers for handling this scenario. Specifically, an emergency
call-taker could see that the location was derived 10 hours before the
call was received, and treat the information as suspect. While preceding
example may occur with a limited frequency, it is certainly more likely
that travel within a town, between buildings in a campus, etc. can lead
to problems if there is spotty coverage of location acquisition. 

Additional implications of this concept:
DHCP method for obtaining location information would show old location
information anyways (e.g. once every 2-3 days or as configured by site
administrators where endpoints are located), so call-takers may become
jaded and accustomed to seeing old information. Need to consider how
location information can be refreshed without over-burdening DHCP
servers, and make sure that all methods of providing location
information have a refresh mechanism to keep the time recent. Perhaps a
compromise between inefficiencies of periodic refreshes and the need to
obtain recent info is to have a “best effort” to obtain location
information again at the time of the call. The idea is to provide the
most recent cached information (maybe from the time the device
registered) at the call initiation time, and to provide a refresh update
of the location after a location sample is obtained at the specific time
of the emergency call.

Argument in favor of strongly stipulating location information refreshes
as mandatory if this feature is adopted: "compromise" solution leaves
the door open for a significant percentage of emergency calls with
outdated location information, in which case call-takers will mistrust
the timestamp and its value will be lost in the big picture.

Thanks,
 
Scott Keagy
Co-Chair, VoIP Operations Committee
National Emergency Number Association
tel:+1(408)221-4793
http://nena.org/voip.htm 

> Of James M. Polk
> Sent: Wednesday, March 17, 2004 7:58 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: Re: [Geopriv] WGLC for draft-ietf-geopriv-pidf-lo-01.txt
> 
> Jon
> 
> Just to let you know (on this list) that I'm finalizing my (2)
> comments
> with appropriate text offerings for review. I should have this done
> this
> evening and I'll post to the list sometime thereabouts.
> 
> At 11:23 PM 3/3/2004 -0800, Allison Mankin wrote:
> 
> >Geopriv-ites,
> >
> >This is the start of a three-week WG Last Call for the Geopriv
> >Location Object Format, draft-ietf-geopriv-pidf-lo-01.txt.
> >Its target status is Proposed Standard.
> >
> >The period is three weeks to allow for the IETF travel and
> >reporting out from this meeting.
> >
> >Send your comments by March 26.
> >
> >Allison, Andy and Randy
> >
> >
> >_______________________________________________
> >Geopriv mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> cheers,
> James
> 
>                                 *******************
>                  Truth is not to be argued... it is to be presented
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 18 Mar 2004 14:58:43 -0500

> to problems if there is spotty coverage of location acquisition.

Color me ignorant, but how does this call get routed?
If it is routed via bad location info in the device, then doesn't it go 
to the wrong place anyway?
If it is routed via the network, then doesn't the network know its 
current location?

-andy