RE: DHCP options for civil locations

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Sunday, December 08, 2002 07:40

> ... an observation that few DHCP options intended for
> application configuration have ever been widely deployed
> (for example, "default www server" and "default irc server")
> so I strongly suggest you think carefully about the usability
> of the option.

... in many standard OS, it's basically impossible for a user
application on a client to get at DHCP data. This is less likely
to be an issue for embedded devices such as IP phones.

[rbh] if this functionality [allowing an application to easily access
DHCP option data] is either required [by legislation or regulation] or
desired [for product differentiation or other marketing or service
reasons] it will be implemented.

Unfortunately, I don't see a better delivery mechanism. You want
something that's close to the physical location of the user, so having
it, say, at the SIP or DNS layer seems counterproductive. (Same with
ACAP, which would also likely be hosted in the 'home' domain, rather
than the 'visited' domain.)

[rbh] it's a fallacious assumption that a DHCP server is at all "close"
to the physical location of the user. I know of several private
networks where the DHCP server is hundreds or thousands of miles from
the DHCP clients it serves. Because of the possibility of intervening
relay agents between a client and server, the two aren't necessarily
"close" in terms of subnetwork addresses.

> Although I can envision several applications beyond emergency response
> for location data, I still have trouble understanding how a
> [centralized] server can know the precise location of the host without
> solving some very difficult configuration issues. Determining the
host
> location with sufficient precision for the intended application, then
> configuring the server without introducing [transcription] errors, and
> finally tracking the location of the host when it is relocated (as
often
> occurs in commercial or educational settings) is not a minor effort.
A
> breakdown in performing any of these tasks invalidates host location
and
> renders the application marginal or unusable.

From what I've heard about traditional 911/112 services, keeping the
address database current is not a new problem. This does not imply that
one should simply say "well, a few addresses are going to be wrong, so
we won't bother at all".

[rbh] yes, E911 services have issues with the correctness of their data,
but consider the source: nearly all are based primarily on the Service
Address of the Local Exchange Carrier's Customer Records system. These
typically are no more than a street address and [possibly] unit number.
Still, emergency services crews are dispatched based on this information
and usually are able to locate the person who initiated a response, even
when a cordless phone is used.

I mention cordless phones as a way of introducing the nagging issue of
actually knowing where the phone is located. Recall that in the United
States, at least, the user is responsible for installing and maintaining
the "inside wire" between the Minimum Point of Entrance and wherever the
telephone set is actually located. The actual location could be in
another building, at a different street address from the listed Service
Address. The situation is somewhat better in businesses and commercial
installations, but the quality of location information is not perfect.

In this particular case, there can be several mapping mechanisms:

- DHCP relay agents located on switches that know which interface a
particular DHCP request came in on; any reasonably well-managed system
will track the current termination point (room) of its LAN
infrastructure.

[rbh] perhaps in some environments, but most commercial installations I
know simply do not bother recording the complete details of a
connection. Switch or hub ports are often just extraneous information
because they are largely interchangeable.

- Some announcement protocol (there are proprietary ones only, as far as
I can tell) where the client finds out the switch and interface number
and then conveys that to the DHCP server, which looks into the local
asset management table

[rbh] I'll acknowledge the possibility of a discovery or announcement
protocol supplying information about it's resources used for a
particular physical connection, possibly even associating that with a
logical connection (IP address and port numbers) -- which is potentially
useful in a number of contexts (security, access controls, environmental
controls, quality of service management, etc.), but I will strongly
object in the DHC Working Group to any requirement that a DHCP server
implementation have a specific configuration behavior. Historically,
the means and methods for configuring a server are specifically "out of
scope" with respect to the protocol definitions, and I cannot see that
changing.

- Manual configuration by MAC address (bad idea if things move and the
asset database isn't kept up-to-date, but easily implementable).

[rbh] I supervised a configuration management group in an organization
that had tens of thousands of DHCP clients. In our experience, the
number of incremental moves, adds, and changes was approximately 10% of
the installed base per month. I submit that such churn is not an
exception, but likely to be the norm in a large, widely distributed
organization.

Compared to the traditional phone system, we have the advantage that
applications can easily display this information to the user. If the
user sees a pop-up every week that says "Your emergency response
location is registered in Room 1234, Main Street, Anytown; if this is
incorrect, please contact your sys admin immediately" and this isn't
true, the user may actually do this. (One reason I like civil addresses
is that users can recognize mistakes in those addresses easily. There's
not much point in displaying the longitude and latitude to a user for
confirmation.)

[rbh] agreed, in some IP phones (but certainly not all!) Civil
addresses are essential for routing emergency services personnel, and
people are generally pretty well adapted to resolving ambiguities and
errors in them, especially if corroborating information is available
such as "cross street" or "between."

> This draft seems prone to failure, so I caution that operational and
> usage requirements be fully explored before advancing this draft.

I think the failure modes are roughly equivalent for both geospatial and
civil locations.

[rbh] I agree with this point and the remaining ones that you made, but
perhaps I didn't state my fear correctly. The failure will likely not
come from using the information in an emergency, but rather the
administrative issues for initially configuring the data for the server
and then for maintaining it. I assert that much of the information
about location of a device is simply not recorded, not reported, and
unlikely to be kept up to date in most circumstances. This may not be
much of a practical impediment to the use of the data in most
circumstances (paramedics responding to a suspected heart attack in an
office building will likely find the victim as long as they get to the
right floor because of local "guides" who await their arrival, for
instance) but there are corner cases where lack of sufficient precision
is a serious flaw (imagine the heart attack victim after hours, with no
one else nearby to guide the paramedics -- in this case, the imprecision
can be fatal!)

It's the data capture, data entry, and data maintenance issues that
worry me, especially if cordless phones or extreme displacement of the
tel set due to exceptionally long cords is considered.

--Barr
Received on Thu Dec 12 23:05:32 2002