Subject: RE: DHCP options for civil locations

From: Marc Linsner <[email-masked]>
Date: Thu, 02 Jan 2003 09:40:35 -0500

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 02 Jan 2003 09:53:04 -0500

> [rbh] how many IP phones use the ISC DHCP client?  I doubt that any
> outside of a development lab do, but I'm sure that the IP phone's clients
> (of various manufacturers) will be able to reach the geolocation data if
> required.

I agree that this is not likely to be a major problem. There are some 
phones that run Linux, but whether they use ISC DHCP, I have no idea.

> [rbh] actually, in most cases, the people who administer DNS are generally
> the ones who administer DHCP, especially now as dynamic updating of DNS
> data by DHCP clients and servers is more widely implemented.

True, but not always. For example, I have a server (edas.info) located 
at Columbia, whose DNS servers are in some other part of the country 
(and where I have no access to anything except A and CNAME records).

DNS also has very different privacy issues: with DHCP, it is easy for 
the device itself to get its own location, but fairly hard for others to 
do so. With DNS, the information is essentially public. Thus, from a 
privacy and control-of-data perspective, DHCP seems much closer to what 
one would want.

> [rbh] this opens an interesting area:  I would imagine that we will begin
> to see IP phones penetrate the dial-up community and other non-static uses
> such as DSL users connected via PPPOE.  In this instance, the ISP has some
> reasonable, though imprecise, knowledge of the client location (using
> the billing or service address) through normal sign-up procedures.  These
> days Yahoo is partnering with ISPs, so one can never tell who might hold
> the client location data.

Even if the DSL or cable-modem provider knows my service location, it 
seems much better if that provider tells *me* that rather than trying to 
figure out who can legitimately request this information. This gives me, 
as the subscriber, control.

I suspect that we'll end up with a hybrid situation, but right now, it's 
rather difficult for the callee such as a PSAP, to determine reliably 
(a) who my ISP is and (b) how they should contact the ISP to get my 
location information. The PSAP only has two identifiers: a SIP address 
and the IP address. The SIP address may not be known to my ISP (there's 
no reason for it to be my SIP provider) and the IP address may be 
temporary or shared (NATs).

The more difficult problem is that building a system where all ISPs have 
an external, secure interface that allows any PSAP to access location 
information seems much harder than a client-centered approach.

The core difference to the phone system is that the entity that knows my 
location has no clue whether I placed an emergency call or not since it 
doesn't "see" the signaling at all. Thus, it cannot include this 
information in the call and cannot readily verify that the PSAP querying 
for information is asking for the right person.

> emergency responders than latitude and longitude, even with the inevitable

Agreed.

> the administrative burden will overwhelm many implementors.

I agree that this will only work if there's a good "OA&M" interface, to 
use PSTN terminology. In general, the classical model of a set of flat 
text files for each server (DNS, DHCP, AAA, SIP, IMAP, etc.) isn't going 
to fly, location information or not.

> Rest assured, the first lawsuit of the family of the poor victim will
> send sys admins scrambling to record the correct information of every
> jack in the place :-)
> 

Yes. There is model legislation for Multi-Line Telephone Systems (MLTS) 
that requires larger businesses to retrofit their PBX with this 
information. It's the law in a few states. (See 
http://www.apcointl.org/) Apparently, it's on the docket for the FCC, 
but not much has happened.

> [rbh] I'm not expecting an Ethereal usage tutorial from you, but I don't
> understand how a laptop plugged into a remote Ethernet jack is able to
> determine the switch port, especially for unmanaged switches.

I was referring to our local (Cisco-based) networks. All Cisco switches 
broadcast this information once a minute, using CDP. See 
http://www.cs.columbia.edu/~hgs/internet/cdp.shtml for the Ethereal 
tutorial :-)

I suspect that 'large networks' and 'unmanaged switches' yield 'high 
turnover rate for sysadmins'...

> [rbh] I agree with all of your common assumptions except the last one:
> 
> - We need a mechanism that's run by either the L2 or L3 service
> provider, not the application service provider.
> 
> [rbh] we should not be specifying who provides the service.

The application-layer (e.g., SIP, IM or email) provider is extremely 
unlikely to have access to reliable device location, thus the requirement.

> does not burden system and network administrators, installers, and

No disagreement there - I think there are business opportunities for 
more integrated network user administration systems here... At the 
protocol level, we can only make sure that the information being asked 
for can reasonably be provided by the entity being asked and to use 
protocols whose implementation burden is low.

> 
> Regards, and best wishes for a Happy New Year!

Best wishes for a civil new year, whatever your geographic location!

> --Barr

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 02 Jan 2003 10:14:32 -0500

> handle geo-location type data.  I agree that in a campus environment, having

I don't qualify except by hear-say, but from what I gather, one of the 
major stumbling blocks in getting Phase II widely implemented is indeed 
the expense of the geographic information systems for PSAPs.

> routing and record storage - warrant an attempt at a system that may be able

I don't understand this remark. For long/lat information, you still have 
to have a database that maps device or jack to a geographic location. 
Why would this be any easier for long/lat than civil?

> this data).  Geo-loc would eliminate the MSAG database and the ALI database.

I don't think so. The MSAG database maps street addresses to ESNs 
(emergency service numbers), i.e., the combination of fire, police and 
rescue services handling a particular location. You would then need a 
database mapping geo coordinates to ESN, which is roughly the same, 
except that you're storing polygon coordinates instead of street names.

The ALI is only needed to map phone numbers to street addresses. Thus, 
the need for the database would disappear if the call request contained

Since emergency crews are dispatched by street address, not long/lat 
("Ambulance 3, please drive to 38.008874 N, 84:29:31.178W" isn't going 
to work too well), with geo information, you'll need an additional 
database. As you said, we'll have this in any event, but I don't see how 
either civil or geo will remove anything but the ALI database.

> the dhcp option number from the loser!).

I agree on the need for both. There is good reason to convey both pieces 
of information, as it helps track errors.

> it could be 'turned off' within DHCP.

One of my motivations was that for most admins of large campuses, civil 
information is much easier to enter than trying to reverse-engineer 
long/lat from a blueprint or campus map.

> couldn't escape liability in the event of a network failure.

I was primarily concerned about private, campus-style environments, not 
public services. Since there are existing geocoding tools (see 
http://www.geocode.com for one), it's no extra work for a 
LEC/cable-ISP/DSL-ISP to convert a subscriber database to long/lat or to 
provide it as-is (civil) in DHCP. After all, these companies already 
need to know where they need to send their service technicians.

> and over again, automatically, at host configuration time, is a good thing.

Indeed. In particular, it will also help with other non-emergency tasks, 
e.g., to help sysadmins track their assets.

---

From: Marc Linsner <[email-masked]>
Date: Thu, 02 Jan 2003 13:33:23 -0500

> the expense of the geographic information systems for PSAPs.

The time consuming stumbling block to getting Phase II implemented was the
location gathering technology, not the PSAP.  Of course, now the carriers
are close to or ready and the PSAPs are gettting up to speed.

> Why would this be any easier for long/lat than civil?

I was referring to the ALI & MSAG databases that are not 'locally'
controlled and require a bunch of redtape and $$ to make a change that takes
24 hours to happen.  Obviously, the wire map database will be
controlled/stored by the end-user instead of the LEC/backend provider.

> either civil or geo will remove anything but the ALI database.
Ah! But today the MSAG database contains ranges of street addresses and
street names that are mapped to ESNs. The whole structure of this database
causes a good portion of the errors associated with the ALI update process
(ALI updates are checked against the MSAG prior to inserting them into the
actual ALI database).  The territorial database would simply be a polygon of
geo-loc coordinates.  If your LO falls in XYZ polygon, route the call to XYZ
PSAP.  Today, if a developer extends a street, or adds new streets to a
subdivision, the PSAP must update the MSAG database.  The keeper of the MSAG
database charges $$ for maintainance services.  The territorial database
would only change with political changes, something that doesn't happen very
often.  It should lower the cost of maintaining this public information
database (like free!).
> long/lat from a blueprint or campus map.

I would venture to guess, that multiple GIS software vendors would be more
than glad to 'assist' any large campus with aerial photos that will show
geo-loc coordinates, in any resolution desired, for every building (or
portion thereof) on campus.  Hmm, it may even be the same people that supply
the PSAP with their mapping software. BTW, I do not work for, or have any
interest in such a company, I am just a casual observer of what has happened
with GIS technology.

> e.g., to help sysadmins track their assets.

I was thinking about new location oriented commercial opportunities. (Would
Domino's pay 25 cents per pizza back to the University to receive the dorm
room location info that called in the pizza order?).

-Marc Linsner-

---

From: Barr Hibbs <[email-masked]>
Date: Mon, 06 Jan 2003 12:16:47 -0800

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 06:41
>
 *** Snip! ***
>
> 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] sorry, but that simply does not work.  We are struggling now to remove
DHCP option numbers that have never been implemented and ones once
implemented for which no new equipment has been manufactured for several
years.  The IESG and IANA do not easily deprecate option numbers once
assigned.

> > [rbh] 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.
>
> 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 still really, truly do not see how provisioning an IP phone with its
location information via DHCP ultimately helps with the stated objective of
enabling emergency responders to know where the telset can be found in an
emergency.  Unless, of course, the IP phone provides the equivalent of an
ANI service with all originating calls (can't be only for calls to "911" or
"999" as callers may dial a general service number such as "553-1234" or
even "0" when they require assistance.)  Yet even with the protocol
mechanism to do this, one which works per regulatory requirements for the
caller-ID service, it remains both a huge administrative burden in my
opinion to provision DHCP servers with the location information, and
unusually prone to errors caused by relocation of the telsets without
updating the databases.

 *** Snip! ***

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 06 Jan 2003 15:45:17 -0500

> unusually prone to errors caused by relocation of the telsets without

There are probably at least three scenarios:

- DSL and cable modem ISPs already have customer billing data. They 
authenticate requests and thus generally know which device just made a 
DHCP request. Thus, this requires a bit of database coupling, but no 
manual maintenance. (I suspect many use PPPoE to assign IP addresses, so 
these mechanisms may need to be extended to that environment as well.)

- Small businesses within a single building only need to configure one 
address or geographic location in their access router. This doesn't seem 
hard if the configuration web page prompts for this information. If 
phones and other devices show this information to the user on occasion, 
it is very likely that somebody will notice very quickly that the 
information needs to be updated after a move.

- Large organizations that span a whole campus can at least provide the 
campus address, which is roughly what you get with today's 911 system. 
Any sysadmin that values his sanity will maintain a port-to-room 
database for daily system maintenance. The organizations that I'm 
familiar with do this already, for several ten thousand ports.

I suspect that in some cases, the largest difficulty is not so much 
maintaining this information, but integrating it into an existing DHCP 
server. From my understanding, standard DHCP servers aren't exactly 
database-friendly. Thus, in addition to the two mechanisms already 
proposed, there's probably room for a third, where the device only 
determines its port number and switch name, e.g., courtesy of CDP, and 
leaves the mapping to, say, the outbound SIP proxy server. (That's what 
we do in our implementation; there's a Perl script in the SIP proxy that 
does a database lookup. Just about anything that can be accessed across 
the network could be used that way.)

Alternative suggestions are most welcome.

Henning

---

From: Barr Hibbs <[email-masked]>
Date: Mon, 06 Jan 2003 13:19:49 -0800

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 06:53
>
 *** Snip! ***
> privacy and control-of-data perspective, DHCP seems much closer to what
[rbh] I wasn't suggesting that we [over-] burden DNS with the location
information, but this does raise the interesting question of how one might
provide a "caller-ID" service for IP phones, within the existing regulatory
framework.

> as the subscriber, control.
[rbh] you've got two thoughts here:  (1) providing calling party information
to legitimate consumers of it, and (2) who controls the distribution of the
information.  As I mentioned before, a "caller-ID" service is one type of
consumer that should be accommodated;  an ANI subscriber (for example, Lands
End catalog order center) is another;  while emergency services is the one
that generated this discussion.  In order to accommodate the first two of
these services (and, in practice, emergency services as well) the IP phone
(if it were the "who" controlling distribution of the information) would
need to have the necessary protocols and database support to provide those
services, along with localized configuration of the IP phone for the three
common caller-ID modes (always provide, always deny, provide on a
call-by-call basis.)

I'm also uncomfortable with giving clients in IP phones ultimate authority
over providing some of this information.  While we haven't yet seen a DDOS
attack on E911 systems from IP phones, I wouldn't discount the likelihood.
If the telset itself decides who can receive location information, then
during a DDOS attack, it certainly would not be likely to supply such
identification.  I will assert that there is an overriding public need for
uniformly supplying location information in several well-understood cases
that it borders on irresponsibility to place determination of who may
legitimately request the data in the client IP phone.

> temporary or shared (NATs).
[rbh] I certainly agree with the difficulties you've given, but also must
point out that DHCP is intended specifically to give out temporary IP
addresses.  The problem gets worse when considering IPv6, in which a DHCP
server isn't even necessary to provision a client host in many cases.

> information seems much harder than a client-centered approach.
[rbh] I'm sure that NeuStar and VeriSign (to name just two) would be very
happy to supply both the databases and the secure means to update and access
them for legitimate users, and I'd be much happier with such an approach
myself.

> for information is asking for the right person.
[rbh] your second point is always a problem, probably unsolvable.  While the
ISP doesn't see any signaling, an authenticated request from a PSAP
requesting location information shouldn't be too much of a problem --
presupposing that the client is configured with the IP address of a location
service that it could supply in a call request.

 *** Snip! ***
> unlikely to have access to reliable device location, thus the requirement.
[rbh] okay, now that you've restated it slightly, I agree with you

---

From: John Schnizlein <[email-masked]>
Date: Mon, 06 Jan 2003 16:14:52 -0500

At 03:16 PM 1/6/2003, Barr Hibbs wrote:

>emergency.  

Let me try to explain in the context of your stated concerns.

>Unless, of course, the IP phone provides the equivalent of an
>even "0" when they require assistance.)  

It is not clear that an IP-phone would need to send its location with every call establishment request. While you are correct that there might be numbers other than "911" that are treated as emergencies, the goal is that the phone's user can control which calls get the location information. A little local configuration is probably necessary in order to maintain privacy for the general case.

>Yet even with the protocol

Relocating telsets, or any other IP host, is explicitly supported. The proposal is that the network infrastructure can assist in determining the location by including a DHCP relay-agent information option that identifies the switch-port. The burden is then reduced to providing the DHCP server with access to the (probably ought to already exist) database of the pre-computed civil (or geographic) location wired to that switch-port. 

One reason for giving the wired IP-phone its geographic location is that both wired and wireless phones that learn their locations through something like GPS would send the same kind of information to the emergency responder.

A point that we have not emphasized, in our effort to show how well this strategy fits the requirements of emergency responders, is that hosts (IP phones or otherwise) could be programmed to send their locations as part of other services as well. If the user wanted directions to the nearest coffee shop of a particular brand, an application could send the host's location to the appropriate service. The key is that the host most directly under the user's control would have the location as a result of dynamic configuration if possible.

John

---

From: Barr Hibbs <[email-masked]>
Date: Mon, 06 Jan 2003 14:15:53 -0800

> Sent: Monday, January 06, 2003 12:45
>
 *** Snip! ***
> these mechanisms may need to be extended to that environment as well.)
[rbh] No!  Unfortunately, as far as we (the DHC Working Group) are aware,
there are no widely-deployed implementations of DHCP Authentication.  In
fact, as small study group has been chartered within the DHC WG to determine
what is wrong with the specifications and to propose solutions to the
problems.

Cable system operators sometimes register the MAC address(es) of (a) client
device(s) attached to a cable modem, but most are finding the administration
of that information and the constant reconfiguration of their DHCP servers
to be a horribly painful experience, and are simply concerning themselves
only with the cable modem itself.

PPPOE is prevalent enough that all the manufacturers of cable/DSL routers of
which I'm aware include PPPOE support.  I suspect that the majority of ISPs
using PPPOE for their DSL customers identify the customer solely on the
basis of a user-ID/password combination and do nothing to prevent multiple,
simultaneous logins...  I know mine doesn't.

> information needs to be updated after a move.
[rbh] a good example of "close is good enough!"

> familiar with do this already, for several ten thousand ports.
[rbh] but ports are not IP addresses, especially when DHCP is involved.  Not
every router or switch is managed or capable of providing any data on port
usage or routing tables in a useful way for location purposes.

> the network could be used that way.)
[rbh] I sort of proposed an alternative in an earlier note, but I'll restate
it now a little bit more fleshed out:

A new DHCP option could provide a list of IP addresses of an identification
server that, using a protocol to be developed, could answer [authenticated]
requests for information about the client.  The information provided by the
identity service should include geographic location (address), and
[customer] name enabling E911, ANI, and Caller-ID services.  The DHCP client
provides the server address to applications in its host system that use it
during VoIP session initiation (and for other applications) along with
appropriate indicators as to uses permitted, for example: only E911 and ANI;
for Caller-ID.  Just as with PSTN-based Caller-ID service, the choice of
"unblocked" or "blocked" resides with the customer.  A mechanism for
updating the identity service database from the client is very likely
necessary, whether that is an application layer function or a network layer
function is to be determined.

--Barr

---

From: Marc Linsner <[email-masked]>
Date: Tue, 07 Jan 2003 09:04:58 -0500

> years.  The IESG and IANA do not easily deprecate option numbers once
sounds like a political problem, not a technical issue.

> unusually prone to errors caused by relocation of the telsets without

If the IP phone knew it's geo-location, it could certainly pass that info
along with any session initiation it choose to, all under control by the
end-user/domain (911 or whatever session it wanted too).  I believe GeoPriv
wants that end-user/domain control.  Obviously, this would require some
changes to the SIP invite (H.323, etc.), our next course of action.  Our
proposal includes an automatic mechanism to 'track' wired telsets as they
move around campus, I don't understand your concern about phones relocating,
if the device acquires it's location every time it plugs into a new jack,
via DHCP, how can this be a problem?  The huge administrative burden of
building the wire map database happens 'one time', then the necessary
database maintenance as the hard wiring changes within the campus (new jack
locations added, moved, etc.).  This already happens today with the
customers that provide phone locations within their campus to the 911 world
(mostly in an archaic fashion).  The alternative, as we see it (and we could
be missing something), is to build some exotic hardware into the phone and
physical infrastructure of the campus to have the phone acquire it's
geo-location by some other means.  Remember, this whole location 'thing' is
a requirement, something most consumers are not willing to pay huge dollars
to satisfy.  If we start adding hardware to the infrastructure and hardware
to the phone, it will drive IP Telephony prices higher than what's
marketable.  If we do nothing, then customer won't accept the technology
because it can't meet local requirements.  Something most of us on this list
do not want to see.

We believe that geo/civil location information IS part of the host
configuration issue, hence DHCP.  One could certainly argue that physical
location is different than layer 3 location, and needs to be done outside of
the DHC server.  We don't see it that way.  The DHC server is passing along
to the client all kinds of layer 3 locations, dns, gateway, name servers,
etc.  Your point about passing the client the layer 3 location of a physical
location server has been thought about, but we deemed it unnecessary as it
won't be a burden on the DHC server to perform this very trivial look-up
task. In your example of providing the layer 3 location of the physical
location server would still require the DHC server to pass along the layer 2
location of the device (circuit ID) so the device could then query the
physical location server with the circuit ID, with a yet to be designed
protocol (assuming a GeoPriv variant).  BTW, the IETF isn't/shouldn't define
what happens inside a DHC server, only the communication protocol.

-Marc Linsner-