0 *H 01 0 +0 *H $SContent-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit  sorry for the long response time, but vacations, conferences, and the holidays conspired against me.... -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, December 13, 2002 06:18 > ... 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] 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. > [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].) [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. 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] 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. > [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. [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. > 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] 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. > [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] 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. > [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 :-) [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. As I said, this isn't a new problem. At least in some jurisdictions, they'll have to do it for PBX extensions. (Speaking from local experience, we have a large number of PBX patch panel location where nobody knows where 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.) [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. > 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 doesn't detract from the general usefulness of address databases. Let me state what I think our common assumptions are: *Snip!* [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. 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". [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. Regards, and best wishes for a Happy New Year! --Barr 0010  *H 01 0 UZA10U Western Cape10U Cape Town10 U Thawte10U Certificate Services1(0&UPersonal Freemail RSA 2000.8.300 021213055318Z 031213055318Z0E10UThawte Freemail Member1"0  *H  rbhibbs@pacbell.net00  *H 0P3e͒׍ڤr "4h,jy!к}W8z$&Kg}Inc?j`vmcW@OBFO3pwtѾFGDH<=^*Y{y`?00.0U0rbhibbs@pacbell.net0 U00  *H Ӄ=ҷǖs0GH9*d [/w[6vFsK5oBssHpA|^~0*k\/ mXj~#T٠E^caC')2z080fErtcvE.0  *H 01 0 UZA10U Western Cape10U Cape Town10U Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H  personal-freemail@thawte.com0 000830000000Z 040827235959Z01 0 UZA10U Western Cape10U Cape Town10 U Thawte10U Certificate Services1(0&UPersonal Freemail RSA 2000.8.3000  *H 032c %E>nx'gڈD)c5*mp<ܮto034qmOe KaU5u'rװ|CBPQ<9TIf- kiN0L0)U"0 010UPrivateLabel1-2970U00 U0  *H 1KG]qSl]y=&b""I'{9$ *8PUl LGl X1B li+@]jy.%݊ ZM>J|Vqo~D.