Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-l o -profile-00

From: "Marc Berryman" <[email-masked]>
Date: Fri, 15 Jul 2005 09:59:02 -0500

Luckily, routing is not dependent on the altitude, floor, sub-floor, or
at least not with the current routing models. The routing of the call is
based firmly in two dimensions. An address -123 Main -, or a coordinate
pair - long, lat - both of which represent a point on the earth.
Supplemental information is often needed by the responders.

3825 is well suited for this supplemental information. Information that
could be very useful the to emergency responders, e.g. "Now I am at 123
Main, but which of the 23 floors did the call come from?"

I'm all for leaving both in and providing all data elements to the PSAP.
Let the PSAP decide which one to base their response on.

Of course I am coming from the Operations side, so I may be missing the
broader picture. 

Marc B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James M. Polk
Sent: Thursday, July 14, 2005 10:32 PM
To: Henning Schulzrinne
Cc: 'GEOPRIV'; Marc Linsner
Subject: Re: AW: [Geopriv]
Quickrandomcommentsondraft-ietf-geopriv-pdif-l o -profile-00

Henning

I wasn't claiming "mine is better", I was just defending 3825 as
suitable, 
when more than one seemed to claim it was not.

I agree we need consensus on what level of precision for each format
needs 
to be present to satisfy certain functions (like routing to a PSAP).
That 
seems like a meaningful discussion - and hopefully a more peaceful one
;-)

At 10:22 PM 7/14/2005 -0400, Henning Schulzrinne wrote:
>James M. Polk wrote:
>
>>However, floor names do change, and unless the build falls down, the 
>>number of floors doesn't - so the 3825 definition of the counting of 
>>floors seems the more precise (if that matters here).
>
>I'm not sure what "precise" means here. Also, floors do get added on
occasion.
>
>I don't think this is a discussion that is going to get us very far.
Some 
>people believe that recipients prefer room locations measured in geo
and 
>in fractional floors, others have their doubts as to the practicality
of 
>that. Experience will tell and the discussion seems to be of interest
only 
>to about 4-5 people.
>
>I'd like to avoid needless complexity for the presumably common case
that 
>both exist and would rather avoid the "mine is better" arguments in
making 
>decisions on routability. Both need some degree of specificity to be 
>routable, down to house numbers for civic and probably at least 100' 
>anywhere on the globe for geo (whatever that translates to in terms of
bits).
>Henning

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: Brian Rosen <[email-masked]>
Date: Fri, 15 Jul 2005 12:42:15 -0400

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.

Sending both is aways fine with me, as long as you know what the data 
really means. Routing has to be fast and unambigous.  If you get 
multiple locations, however they are represented in the signaling, you 
need to choose one to route on.  To me, that would be the "orignal", 
civic or geo.  Of course we may have the problem of multiple locations 
because multiple entities have their own mechanisms.  We need ways of 
representing them so that we can decide which of them to use for 
routing.  This is a "truth in labeling" problem.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 15 Jul 2005 15:31:11 -0500

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.

cheers,
James

                                 *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Jul 2005 23:00:53 -0400

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:
>> 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.
> 
> 
> 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 
> 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
> 
>                                 *******************

---

From: "Tim Dunn" <[email-masked]>
Date: Fri, 15 Jul 2005 21:40:30 -0600

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
[email-masked]<mailto:[email-masked]>

  ----- Original Message ----- 
  From: Henning Schulzrinne<mailto:[email-masked]> 
  To: James M. Polk<mailto:[email-masked]> 
  Cc: GEOPRIV<mailto:[email-masked]> ; Marc Linsner<mailto:[email-masked]> 
  Sent: Friday, July 15, 2005 9:00 PM
  Subject: Re: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo -profile-00

  Henning

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

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 16 Jul 2005 15:44:19 -0400

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: [email-masked] [mailto:[email-masked]] 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
[email-masked]

----- 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

Henning

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

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 16 Jul 2005 15:40:19 -0500

At 03:44 PM 7/16/2005 -0400, Brian Rosen wrote:
>The world is changing.

and apparently some things don't change...

sigh

>I think we want response to
>to the responder

as in the "first responder"?

If so, are you suggesting they (the police man/woman, or fire man/woman) 
actually get the raw PIDF-LO feed and are left to their training to figure 
it out?

Don't you think this will either be interpretted by someone trained to know 
this information, or by some application programmed to interpret this 
information?

>, and we have to assume they are not from the same
>organization.

wow, on the one hand we have to assume the emergency call desk contacted is 
the same organization (because they both are from the same university or 
federal agency), therefore we need this level of precision, yet here you 
are saying we have to assume they are from different organizations - and 
different organization cannot possibly be expected to know the same 
information.

which is it?

A wireless client on the 30th floor of a building in NYC that isn't 
controlled by Columbia U. should only allow other Columbia U endpoints 
access onto their network.  If that's true, then the routing proxy for that 
endpoint when it calls 911 will be a Columbia U Proxy. which MUST only 
route the call to what IT chose as the PSAP or internal emergency uri.

If altitude matters in this case, Columbia U is in total control of it from 
the endpoint to the routing Proxy.

Where's the problem?

The same WILL BE TRUE for federal agencies sharing an office building with 
other organizations.  They will control their endpoints, and their APs, and 
their infrastructures and their routing Proxies and THEREFORE who that sos@ 
message gets mapped to.

where's the problem here?

>Without some kind of mapping to, I guess, strings, it's not
>possible to use RFC3825 Altitude value when AT=2.

the only way anything knows the unit of measurement is have it be told the 
unit of measirement.  3825 clearly states there is a unit of measurement 
indicating "FLOORS", and provides a means for understanding when a floor is 
not a whole numbered floor, but a SUBFLOOR, *and* even a means for 
determining WHICH ONE of the subfloors is being reference.

The PSAP operator's station will know how to make this unit of measurement 
displayed properly. That will lead the responders to the right floor.

Ok, so, how hard would it be in this rosey future you replied to Tim with 
is it unreasonable for existing and future construction permits require the 
correct population of some database correlating that in building X, a 
PIDF-LO with a geo format, that floor 1.1 = "mezzanine"? How many times 
would that information need to be entered? Once? For new construction, this 
is done before anyone CAN call 911. For existing buildings, this can be 
done over the period of years, based on local policy (read: law/regulation 
to update logical floorplans).

>It is possible if you

well, then you have to personally know if "0" is for ground, or for mean 
lowest low tide, or some other starting point - cuz without that, and I 
tell you I'm at 318m above "something" - where am I? I would be below the 
ground level by quite a bit if I were in Denver (being the mile high city).

>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.

why would we even consider deprecating a useful information element? That's 
the only way 3825 could be revised to satisfy what you're talking about - 
even if you're not calling for it to occur.

>I just

that makes one of us

If you want to go down this path some more, when's the last time you were 
in a hotel elevator and pressed the "1" button to get to the ground floor?

Most hotels I stay in, the ground floor is called "L" for "Lobby".

So, does this mean I can say I don't want to see an FLR element in a 
PIDF-LO populated with anything other than <FLR>lobby<FLR/>?

I believe you're confusing raw information with how it will be interpretted 
by configurable applications and trained personnel.

cheers,
James

                                 *******************