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