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

"Tim Dunn" <timothydunn01@msn.com> Sat, 16 July 2005 21:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuPK-0005X8-AM; Sat, 16 Jul 2005 17:41:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuPG-0005Q3-R2 for geopriv@megatron.ietf.org; Sat, 16 Jul 2005 17:41:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03150 for <geopriv@ietf.org>; Sat, 16 Jul 2005 17:41:08 -0400 (EDT)
Received: from bay106-dav9.bay106.hotmail.com ([65.54.161.81] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtusJ-0002qD-Mw for geopriv@ietf.org; Sat, 16 Jul 2005 18:11:14 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Jul 2005 14:40:55 -0700
Message-ID: <BAY106-DAV9D643D0C5FC62D7699F44AFD30@phx.gbl>
Received: from 65.54.161.200 by BAY106-DAV9.phx.gbl with DAV; Sat, 16 Jul 2005 21:40:54 +0000
X-Originating-IP: [65.54.161.200]
X-Originating-Email: [timothydunn01@msn.com]
X-Sender: timothydunn01@msn.com
From: Tim Dunn <timothydunn01@msn.com>
To: 'Henning Schulzrinne' <hgs@cs.columbia.edu>, 'GEOPRIV' <geopriv@ietf.org>, Brian Rosen <br@brianrosen.net>
References: <MC6-F591NFTdBlacWG60008948c@mc6-f5.hotmail.com>
Subject: Re: AW:[Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo -profile-00
Date: Sat, 16 Jul 2005 15:39:04 -0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: MSN 9
X-MimeOLE: Produced By MSN MimeOLE V9.10.0011.1703
Seal-Send-Time: Sat, 16 Jul 2005 15:39:04 -0600
X-OriginalArrivalTime: 16 Jul 2005 21:40:55.0443 (UTC) FILETIME=[0BC4E630:01C58A4F]
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7
Cc: 'Marc Linsner' <mlinsner@cisco.com>, "'James M. Polk'" <jmpolk@cisco.com>
X-BeenThere: geopriv@ietf.org
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:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0077720224=="
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

The issue, again, is routing a call to a Primary PSAP.  The Primary PSAP is assigned based upon an X and Y (or a civic address) of a particular point on the ground.  When that PSAP receives the call, there is a determination of what unit is to be dispatched to that address.  It is in the determination of response (fire, medical, law enforcement) where the -z becomes important, so the first responder can find out the problem and ask for other help.  

To the best of my knowledge, there isn't a federal PSAP that is wanting/waiting for the routing of a 911 call because the Dept. of Transportation office on the 4th floor (or the mezzanine or garden level or whatever it is called) of a building which is half office, half hotel has called for medical assistance, fire or because of a crime in progress.  The responding unit is a First Responder (police, fire or EMS) who is dispatched by a dispatcher who has received a request from the Primary PSAP as a result of that 911 call.  The first response unit is based upon written agreements or local custom knowing what is in that building and the nature of the call.  I agree, -z is needed to be unambiguous as a part of the information delivered to the RESPONDER.  In the emergency models, I don't believe routing decisions require -z, but it is nice/critical to have it when the call data are displayed at the PSAP.  

In the commercial model (pizza delivery person) you seem to imply the 5th floor would want to be routed to a different Pizza Hut than the 4th floor.  I'll suggest both floors want their call routed to the same Pizza Hut.  And, -z is not as critical in this model as typically the Pizza Hut call answerer (by their training) is going to validate the location on their screen with the caller.  

Now, in both emergency and commercial models, here's where the meters versus floors discussion comes into play.  From the Pizza example, do I want my pizza on the 4th floor, mezzanine or 135 meters above ground (so at 3 meters average level of a floor, that would be the 41st floor) or 6000 feet above sea level?  I'll suggest that this type of resolution is actually done by the calltaker ("What floor/room can we deliver your pizza, sir?"), not by any location determination method.  In the emergency situation, again, things are different because a caller may be unconscious and unable to respond to the "what floor are you on" question.  It is much better to tell the responder "garden level" or "41st floor" or "check floors 1-5".  135 m above ground tells them nothing (unless they have an altimeter with them).

Tim

  ----- Original Message ----- 
  From: Brian Rosen<mailto:br@brianrosen.net> 
  To: 'Tim Dunn'<mailto:timothydunn01@msn.com> ; 'Henning Schulzrinne'<mailto:hgs@cs.columbia.edu> ; 'GEOPRIV'<mailto:geopriv@ietf.org> 
  Cc: 'Marc Linsner'<mailto:mlinsner@cisco.com> ; 'James M. Polk'<mailto:jmpolk@cisco.com> 
  Sent: Saturday, July 16, 2005 1:44 PM
  Subject: RE: AW:[Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo -profile-00


  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: geopriv-bounces@ietf.org<mailto:geopriv-bounces@ietf.org> [mailto:geopriv-bounces@ietf.org] 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
  timothydunn01@msn.com<mailto:timothydunn01@msn.com>


  ----- 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
  Geopriv@ietf.org<mailto:Geopriv@ietf.org>
  https://www1.ietforg/mailman/listinfo/geopriv<https://www1.ietforg/mailman/listinfo/geopriv>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv