RE: DHCP options for civil locations

I'm not an expert here, but I believe that the wireless folks have
been required to provide a database that translates geo loc to
civil loc.  PSAPs require civil loc.  I expect that the actual responder
would like both - he wants to know the street address, but he probably
can carry a GPS system that could confirm he is exactly where he is
supposed to be.  Requiring that the PSAP maintain the database is 
probably impractical; the politics are that new fancy systems like
VoIP have to pay the costs of new technology -- the 911 (fill in your
local number here) system doesn't do that.  It's not reasonable to
do translation in real time with an aerial photo, you need to be able to 
translate a geo loc into a specific street number, floor, etc, and
putting that data on the aerial photo is constructing the database.

I do think that the "territorial" database, which is used to decide
based on a geo loc which PSAP serves the location, is being constructed,
as you say, and we want to use that.

Brian

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner <at> cisco.com]
> Sent: Thursday, January 02, 2003 9:41 AM
> To: rbhibbs <at> pacbell.net; geopriv <at> mail.apps.ietf.org
> Subject: RE: DHCP options for civil locations
> 
> 
> > [rbh] sorry, I thought that we were coming to agreement.  I 
> definitely
> > agree with your assertion that civil data is generally more 
> useful for
> > emergency responders than latitude and longitude, even with 
> the inevitable
> > imprecision.
> 
> We should probably let the emergency responders offer an 
> opinion on civil
> location verses geo-location (lat/long).  It would make one 
> think that since
> all wireless phase II location information is arriving at the PSAP as
> geo-location suggests that the emergency responders may 
> already be able to
> handle geo-location type data.  I agree that in a campus 
> environment, having
> the civil location, known to locals, would benefit the 
> responders, ie -
> 'payphone in section G12 of football stadium'.  But, IMO, the 
> downsides of
> the civil location scheme - backend databases required to provide call
> routing and record storage - warrant an attempt at a system 
> that may be able
> to utilize common tools with well-known data types (note: economies
> associated with such a system, in addition to other 
> applications for using
> this data).  Geo-loc would eliminate the MSAG database and 
> the ALI database.
> Geo-loc would require a call routing system based on a 
> territorial database
> whereas 'anything inside this box - send the call to XYZ PSAP'.  This
> territorial database would be much easier to maintain than 
> the current MSAG
> database - only political boundary changes would cause 
> database changes.
> BTW, such a territorial database is 'in trial' right now. 
> Currently, any new
> street or address number extensions cause MSAG updates.  Most mapping
> systems are actually aerial photographs, which when coupled 
> with floor data
> (as outlined in our geo-loc LO draft) could aid the 
> responders in finding
> the caller in section G12 of the football stadium.  I believe 
> there is room
> for both location data types, let the best one win (we can 
> always take back
> the dhcp option number from the loser!).
> 
> > [rbh] agreed, perfection is probably not possible, but I 
> came at this
> > topic from a review of an Internet-Draft that specified latitude and
> > longitude with a maximum precision of approximately 3 mm.  
> That's why I
> > questioned the difficulties in obtaining and maintaining 
> the location data
> > for a DHCP server to distribute to its clients.
> 
> I don't believe anyone is suggesting a requirement that 
> geo-loc data for
> emergency calling purposes must be 3mm resolution.  In fact, 
> in the sematics
> draft, we gave a resolution value that closely matches 
> desired emergency
> responder resolution of 7000sq.ft.  The high resolution in 
> the draft is an
> attempt to future-proof the LO, somewhat.  Since mapping 
> system vendors are
> claiming 3cm resolution in current products, maybe we should 
> add a few more
> bytes to the geo-loc LO.
> 
> >
> > [rbh] not at all.  I just want to be sure that the realities of the
> > provisioning and database maintenance process are not 
> overlooked in the
> > move to supply location information via DHCP.  My instincts 
> tell me that
> > the administrative burden will overwhelm many implementors.
> 
> This burden isn't be caused by the data type, it's caused by local
> policy/regulation.  We are attempting to provide tools that 
> will assist with
> the burden. In locations that currently require PBX admins to provide
> location information for each phone, the admins are already 
> tracking phone
> locations - the burden is already in place!  Obviously in 
> areas where there
> is no policy/regulation forcing an admin to do this, we are 
> suggesting that
> it could be 'turned off' within DHCP.
> 
> >
> > [rbh] I don't follow liability torts at all, but I don't 
> believe there has
> > been a precedent-establishing case to date (involving land lines or
> > cordless phones) or this would be a moot point:  in the 
> aftermath of a
> > successful action there would have been product modifications (or
> > withdrawal of products from the market) and new self-registration
> > procedures as well as a flurry of retrofits and records 
> clean-up.  I'm
> > more inclined to believe that legislation mandating the 
> provisioning of
> > location information to aid emergency services will be 
> widely adopted, but
> > with limitations on liability and a long timeframe for 
> implementation to
> > be completed.
> >
> 
> It's fairly common knowledge that LECs are exempt from 
> liability from a
> failure in the 911 network.  The LECs wouldn't provide the 
> service if they
> couldn't escape liability in the event of a network failure.
> 
> > [rbh] this is perhaps the only area where we truly 
> disagree:  I contend
> > that implementation issues are crucial to successful and widespread
> > deployment of standards.  There are several RFCs, sometimes covering
> > entire services, that are not widely implemented because of 
> the difficulty
> > of administering them.  For the geolocation service to be 
> successful, it
> > must not be difficult to setup and operate.  I am 
> advocating the careful
> > consideration of administrative effort for any proposed 
> service so that it
> > does not burden system and network administrators, installers, and
> > technicians.
> 
> Not much disagreement with this statement.  That's why we think that
> building the location database (wire map) 'one time', then 
> utilizing over
> and over again, automatically, at host configuration time, is 
> a good thing.
> 
> -Marc Linsner-
>