Re: DHCP options for civil locations

> My only issue with this draft is that, like the Polk/Lisner/Schnizlein
> draft, it is intended to convey essentially application layer
> information through a protocol intended primarily for configuring lower
> layers. This does not make the draft unworkable, unusable, or any other
> sort of "un-" but is just 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.

I agree in part. We've gone down this path before (e.g., the SIP
outbound proxy option). I suspect that this is partially due to the fact
that 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.

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

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

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.

- 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

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

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

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

Even if the precise room or floor-level location is wrong, the building
or street address is likely to remain correct.

This is all about probabilities - increasing the probability that an
emergency caller can be quickly located. There are no certainties here.
After all, we use maps and phone directories even though we know that
they have mistakes.

>
> --Barr Hibbs
>
Received on Sun Dec 8 10:41:50 2002