RE: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV

"Marc Linsner" <mlinsner@cisco.com> Thu, 10 July 2003 13:29 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01209; Thu, 10 Jul 2003 09:29:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abTp-0007Fm-9k; Thu, 10 Jul 2003 09:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abTC-0007CW-Fn for dhcwg@optimus.ietf.org; Thu, 10 Jul 2003 09:28:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01191 for <dhcwg@ietf.org>; Thu, 10 Jul 2003 09:28:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abTA-0002kp-00 for dhcwg@ietf.org; Thu, 10 Jul 2003 09:28:20 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19abT8-0002kW-00 for dhcwg@ietf.org; Thu, 10 Jul 2003 09:28:18 -0400
Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 10 Jul 2003 06:30:45 -0700
Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6ADRipZ003754; Thu, 10 Jul 2003 06:27:44 -0700 (PDT)
Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA08849; Thu, 10 Jul 2003 06:27:42 -0700 (PDT)
From: Marc Linsner <mlinsner@cisco.com>
To: 'Greg Troxel' <gdt@ir.bbn.com>, "'James M. Polk'" <jmpolk@cisco.com>
Cc: 'John Schnizlein' <jschnizl@cisco.com>, dhcwg@ietf.org, geopriv@mail.apps.ietf.org
Subject: RE: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV
Date: Thu, 10 Jul 2003 09:27:41 -0400
Message-ID: <003f01c346e7$0b85be90$200d0d0a@mlinsnerzk7abh>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <rmi7k6rzavt.fsf@fnord.ir.bbn.com>
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Greg, thanks for the input, wish we could have chatted 12 months ago :^)

> 
> This still begs the question of why use geodetic coordinates instead
> of a civil location, if the latter is what you need.  I presume the
> civil location option serves the latter purpose.

Civil location obviously works well for emergency services when summoned
from a known building. Standardization of civil location for transport
is another issue, especially on a global basis (how many different
'datums'?), and Henning is working feverishly on this.  One reason
behind geo-loc is due to the fact that in the US, PSAPs that are Phase
II wireless enabled are already receiving lat/lon/alt from the wireless
vendors.  PSAPs today are requesting GIS systems that are aerial photos
with a very high degree of resolution (3cm).  They have the ability to
pinpoint the geo-loc received from the carrier onto the map for a very
accurate location.  Obviously maps will supply civil location given a
geo-loc.  So, in an attempt to find a single object type for emergency
services location, geo-loc will serve all, where civil will not. I do
believe that both types have a place and are needed for several years.

Another aspect, geo-loc is machine to machine language, sometimes not
easily interpreted by humans, whereas civil location can be viewed as
the human interpretation of the geo-loc.  Since geo-loc info can be
turned into civil location with a variety of means (very cheaply), why
not use the much smaller, easier to transport, 'what we thought was more
standard' geo-loc for machine to machine communication and let the
wonders of our modern machinery convert it to something a human can
understand?

> 
> lat/lon/floor still seems odd to me.  Floor will matter only in large
> buildings, and those tend to be close together (in cities).  This
> environment (urban canyon) is precisely where GPS works the least
> well, due to blocked sky views and large amounts of multipath
> interference.  So here, I think a civil location is really desired.

We are advocating that this geo-loc configuration information be passed
from a DHC server to a wired device that would not have a GPS installed.
The wire map database could be built from a gps, or a gis type service
that would supply the geo-loc coordinates to a building operator for use
in the wire map. The geo-loc would show up on the PSAP GIS map and show
quadrant of the building along with floor of the caller.  It may also be
desirable that the GIS software hold any other 'local knowledge' that
the building operator and emergency responders deem necessary.

We also envision that there is nothing wrong with the PSAP receiving
both the geo-loc and civil loc information at call setup time if
available.  Obviously SIP and GeoPriv have work to do to pass this
information along.

So in our trek to utilize a more 'standardized' method to express
location, we are now finding that geo-loc is almost as ugly as civil
location in this respect.

Are you going to be in Vienna?

-Marc Linsner-


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