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(_at_)cisco(_dot_)com]
Sent: Friday, April 20, 2007 10:14 AM
To: Brian Rosen
Cc: 'Brian E Carpenter'; 'GEOPRIV WG'; 'Dawson,Martin';
ietf(_at_)ietf(_dot_)org;
'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(_at_)cisco(_dot_)com]
Sent: Friday, April 20, 2007 9:39 AM
To: Brian E Carpenter
Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf(_at_)ietf(_dot_)org; '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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf