RE: DHCP options for civil locations

comments in-line

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

[ml] DHC is one place to perform this function, but I think 802.1X would
ALSO be a good place to convey location information to a hardwired host. I
believe both mechanisms (DHC & 802.1X) should provide this capability (using
the same location object). This would give implementors the choice that
would fit their individual needs.

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

[ml] IP Telephony exacerbates the emergency responders dilemma of finding
the person in need. The antiquated mechanism in use in today's PSTN/ALI
update process (24 hour average update time) would never even begin to
support the mobility afforded to a hardwired IP telephone device, not to
mention the wireless device. We are trying to accomodate the hardwired
devices only, wireless obviously has other issues to deal with. Our hope is
that the location object would fit all environments, one just needs to
change the discovery mechanism.

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

[ml]If the netheads want to assume the responsibility of the bellheads, they
will have to conform to rules and regs that govern the bellheads. Most PBX
admins know with reasonable accuracy where their ports are connected to.
Most Net admins don't care. Convergence means the best and worst of both
worlds.

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

[ml]Alternative - Keep your phone system on the TDM PBX and keep the current
admin staff for that environment!

-Marc Linsner-
Received on Fri Dec 13 14:22:14 2002