Yup. There are no mechanisms that work when the Pringles cans come out other than actual endpoint measuring mechanisms (like GPS), which have their own limitations. The standards recommend methods for users to override the automatic mechanisms when they do things like Pringle can extensions. There are a set of security issues on THAT, but it's still a workable notion. The Cablelabs guys and individual MSOs have looked at this, and most believe they can deploy a DHCP based location infrastructure that works pretty well. The "pretty" part is mostly the problem of cablemodem moving. Nothing is perfect, nor does it need to be. I think it's good enough, although I'd really like them to be advancing on detecting cablemodem moves. At least that error source is a deliberate user action which is really already prohibited by contract. This whole area is complex because there isn't anything that works always. There have to be options, both for access network operators, device manufacturers and even end users to deal with all the variations in reality that occur. And again, nothing is going to be perfect. Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@xxxxxxxxx] > Sent: Friday, April 20, 2007 10:14 AM > To: Brian Rosen > Cc: 'Brian E Carpenter'; 'GEOPRIV WG'; 'Dawson,Martin'; ietf@xxxxxxxx; > 'Allison Mankin'; 'John Schnizlein' > Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums > > Brian Rosen wrote: > > 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. > > > > That's only because there's an out of band arrangement with the MSO > and the subscriber. DHCP itself gives no such information. Wireless > substantially confuses the matter too. All it takes is two Pringle's cans > to cast that relationship in doubt. > > Mike > > Brian > > > > > >> -----Original Message----- > >> From: Michael Thomas [mailto:mat@xxxxxxxxx] > >> Sent: Friday, April 20, 2007 9:39 AM > >> To: Brian E Carpenter > >> Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf@xxxxxxxx; '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 > >> Ietf@xxxxxxxx > >> https://www1.ietf.org/mailman/listinfo/ietf > >> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf