RE: AW:[Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo -profile-00

["Brian Rosen" <[e-mail]>]

The world is changing.  Technology makes things possible now that wasn’t
possible before.  Just because that’s not the way we do it now, doesn’t mean
we don’t want to; often it’s because we couldn’t.  In this case, I don’t
think we are arguing we want to wholesale change routing of emergency calls
in North America.  I think we are asking that it be possible to route based
on, among other things, z.  I don’t think we have to optimize for it; just
make it possible.  To route, or to respond, we need z to be unambiguous;
whatever assumptions were made by the creator of the location information
has to result in the user (router, dispatcher, responder, pizza delivery
person,…) being able to get to the right place.  I think we want response to
be reasonable without requiring information that cannot reasonably be known
to the responder, and we have to assume they are not from the same
organization.  Without some kind of mapping to, I guess, strings, it's not
possible to use RFC3825 Altitude value when AT=2.  It is possible if you
just always make altitude meters.  

This is why propagation of the RFC3825 AT=2 option seems, to me, to be a bad
idea.    On reflection of the needs for routing and responding to multistory
buildings, where there is no reasonable way to interpret the value of the
altitude by the contents of the Altitude field when AT=2, without
information which seems difficult to assume the recipient can get, I
conclude it was a nice idea that doesn’t work; we should not use it, and we
should not copy it into PIDF-LO.   I see no need to revise RFC3825.  I just
don't want to see the mu=floors option in PIDF-LO.

Brian

________________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Tim Dunn
Sent: Friday, July 15, 2005 11:40 PM
To: Henning Schulzrinne; GEOPRIV
Cc: Marc Linsner; James M. Polk
Subject: Re: AW:[Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo
-profile-00

First let me introduce myself to the list.  My name is Tim Dunn.  I
currently operate my own consulting firm, but was a principal product
manager for Openwave/Signalsoft during the time the wireless location
standards for emergency services were being promulgated and then implemented
in the US.  Prior to that, I was a PSAP manager for the City and County of
Denver.  I maintain my standing within various NENA technical committees,
having participated in those committees for some 7 or more years and have
participated in various FCC, ATIS, ETSI and other forums.
 
I've been watching this thread over the past couple of days and find I have
to respond.  As a point of reference, in Denver, we had a building (a movie
theatre) which had the lobby in Denver, and the theater itself in a
neighboring jurisdiction.  In cases such as these (to include WTC, the
Interchurch Building and the like) there are typically agreements which have
been set in place which discuss who is the first responder to a particular
address, such as this movie theatre.  
 
Neighboring jurisdictions spend a great deal of time determining who is the
first responder for whole addresses, corresponding to the city, county and
sometimes state boundaries, not who occupies floors 1, 3 and 4 of a
building.  If there is some sort of question as to which jurisdiction
responds, the PSAP that is responsible for answering that call generally has
responsibility for getting that call to a dispatcher who can send the
correct unit(s).  This would be local police, fire or EMS or some other
response arrangement such as mutual aid or calling the FBI or University
Police or whatever arrangement has been agreed upon.
 
So, I'll suggest from the perspective of routing the call to the PSAP,
routing on -z is not critical.  It is much more critical to provide as
accurate a -z as possible (be it attached to Geo or Civic message format) to
the PSAP calltakers' screens so they can provide it as a more granular
location to the responding unit when they arrive.  
 
Tim Dunn
Timothy N. Dunn Consulting
[e-mail]
 
 
----- Original Message ----- 
From: Henning Schulzrinne 
To: James M. Polk 
Cc: GEOPRIV ; Marc Linsner 
Sent: Friday, July 15, 2005 9:00 PM
Subject: Re: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo
-profile-00

I don't know how to estimate this percentage, but I have a local 
example: Columbia University occupies part of a building called the 
Interchurch Building on 125th Street in Manhattan (called that since it 
is also occupied by the HQ offices of a number of Christian 
denominations). In that particular case, they are actually spread across 
non-adjacent floors and maybe even partial floors.

We discussed other examples, such as high-security or clandestine 
installations in large office buildings. (The "classical" example were 
the offices of the ATF and CIA in the WTC.)

I agree that this is not likely to be common, but not terribly difficult 
to support, either, should the need arise in the future. Given that 
z-level information is carried in both civic and geo-derived formats, I 
don't see much of an issue should somebody decide to factor that into 
making routing decisions.

Henning


James M. Polk wrote:
> At 12:42 PM 7/15/2005 -0400, Brian Rosen wrote:
> 
>> Henning has given examples where routing is dependent on z.  One is 
>> where you have an enterprise, which could be a university, which has 
>> its own response capability.  The enterprise could occupy a portion of 
>> a high rise.
> 
> 
> ok... so what is the percentage of these cases really?
> 
> How often will z be a factor in the routing decision?
> 
> A tenth of a percent of all 911 calls made?
> A hundreth of a percent?
> a ten-thousanth of a percent?
> even less of a percent?
> 
> We're engineers who want to build an architecture as good as we can, but 
> we can't take the case of the above percentages of a chance to steer our 
> efforts. That's attempting to achieve too much without the imperical 
> evidence of experience to make those decisions.
> 
> I'm a statistician by nature, and I deal in Standard Deviations, and 2 
> is a good number to work towards, 3 is excellent, and 5 is unrealistic. 
> The percentages above are getting past 4 SDs and up towards (and past) 6 
> SDs.
> 
>> Brian
> 
> 
> 
> cheers,
> James
> 
>                                 *******************
>                 Truth is not to be argued... it is to be presented.


_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietforg/mailman/listinfo/geopriv


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