Re: DHCP options for civil locations

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

I also since found that the ISC DHCP software has a new API, called
OMAPI. It apparently allows object-retrieval access to the local DHCP
database, although it is unclear to me whether this applies to the
server side or the client side or both. If somebody else knows more
details, I'd appreciate hearing about your experiences.

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

They are at least likely to be run by the same network administrator,
which isn't true for DNS, ACAP and SIP, to pick a few examples. If you
know some other mechanism, I'm very interested. (There are better
solutions, such as port-based broadcast approaches, but they are not
standardized at all and are barely documented. Examples include CDP
[Cisco] and EDP [Extreme Networks].)

Having the network admin determine location is about the only reasonable
approach. Yahoo! or my SIP provider has no clue and has no mechanism to
reach into my network attachment point.

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

This happens to be very close to the information that's in my draft, so
I don't understand your comment.

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

All true, but this just shows that even the PSTN, with a much simpler
wiring structure, has issues, so it's unrealistic to expect perfection
in the IP network.

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

At least three large universities that I'm familiar with (first hand or
through a paper by Deep Medhi and his students at UMKC) do track jack
locations. These include University of Missouri Kansas City, Columbia
University and the University of Kentucky.

Also, there are probably two sub-cases:

- states where local law requires tracking PBX phone locations within a
large enterprise (there are about half a dozen and there may eventually
be an FCC regulation; see the APCO web site for details)

- other states

In the former category, anybody installing a VoIP system will have no
choice but to get his house in order.

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

I have no intent to tell anybody what magic, crystal ball, divining rod
or database they should use to populate this data. I'm just providing
examples. No different than any other DHCP data.

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

That's why I said it's a bad idea :-)

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

As usual, we can try to cover as many as possible. In some cases, this
isn't necessary (small business where, say, the SIP outbound proxy
server can know the location with confidence, since all devices are
going to be in one office - I'm assuming no dial-in or VPN into this
network), in others, it's not feasible.

Are you suggesting we shouldn't try since it isn't going to be feasible
in 100% of the cases?

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

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

As I said, this isn't a new problem. At least in some jurisdictions,
they'll have to do it for PBX exensions. (Speaking from local
experience, we have a large number of PBX patch panel location where
nobody knows where the the wire ends up. The only way to find out would
be to dial all 200 numbers until the phone rings. It's a little easier
with a modern Ethernet installation - plug in laptop, fire up Ethereal
and within one minute, you have the switch port.)

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

I'm a little confused by this statement. I don't see how we can fix this
problem, but that doeesn't detract from the general usefulness of
address databases. Let me state what I think our common assumptions are:

- Locating emergency callers within a large campus or building is
important, regardless of technology.

- In some jurisdictions, this is mandated by law, regardless of whether
the communications device is using analog wires or IP packets.

- In all cases, the information has some probability to be somewhat
wrong (in other words, some pieces may well be right); the important
consideration is *expected* (average) time to find the caller. This is
one reason I provide the different options of what location is being
declared, so that the receiver of that information can make an educated
guess of what to trust. (Switches and DHCP servers don't move nearly as
often as PCs and IP phones and are more likely to be moved by sys admins
rather than users.)

- We don't want to tell people how to populate such databases, as the
mechanisms vary. (If at all, these types of issues are probably better
handled by organizations such as NENA or TIA, since that's their bailiwick.)

- We don't want to tell people how to implement user interfaces.

- We need a mechanism that's run by either the L2 or L3 service
provider, not the application service provider.

I'd be glad to receive additional wording that you would find helpful in
the draft to clarify any issues. I don't think I want to get too deeply
into operational issues since at least my wording would be likely no
more useful than the "keeping track of network devices or jacks is a
pain, get used to it".

>
> --Barr
Received on Fri Dec 13 09:16:12 2002