The cable systems use the MAC address of the DOCSIS modem to determine which subscriber is asking for location. It's not perfect, because it is possible to move a DOCSIS cablemodem from one house to another within some area (often the service area of the CMTS, but in many systems, less than that). The ability to move without detection is a problem the have for other revenue sources and there is some effort being put into systems to detect that kind of thing. The incidence of moving the cablemodem without notice is apparently very small.
You don't get the location of the server, you get the location of the client. Brian > -----Original Message----- > From: Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Friday, April 20, 2007 9:39 AM > To: Brian E Carpenter > Cc: 'GEOPRIV WG'; 'Dawson,Martin'; [email protected]; 'Allison Mankin'; 'John > Schnizlein' > Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums > > Brian E Carpenter wrote: > > On 2007-04-20 09:21, Hannes Tschofenig wrote: > >> DHCP is not a great choice in a mobile environment and also not when > >> it comes to more complex location representations. > > > > Why can't a mobile system have a locally valid DHCP record (+/- the > > length > > of a wireless link)? For that matter, why couldn't a DHCP server have > > real-time triangulation data, if it exists at all? > > > > Do you mean more complex than can be expressed by RFC 4776 and RFC > > 3825 together? > If you look at DOCSIS cable, a single head end can subtend a huge amount > of cable in a single bridged domain. I seem to recall that in a rural > Canadian > MSO I worked with it was 10's if not 100's of miles. I have no clue how > accurate GEOPRIV tries to be, but it sure seems that if the location of > the > headend/dhcp relay is only piece of information you have, your accuracy is > going to be pretty lousy in many cases. If this information is intended > for > first responders, it seems that all you're doing is pointing to the > right haystack > to start searching for the needle. > > Mike, who probably shouldn't open his mouth here > > _______________________________________________ > Ietf mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
