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

["James M. Polk" <[e-mail]>]

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
>be reasonable without requiring information that cannot reasonably be known
>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
>just always make altitude meters.

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


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

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
>don't want to see the mu=floors option in PIDF-LO.

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.


>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


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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