" A problem exists within existing RFCs that provide location to the
UA ([RFC3825] and [RFC4776]). These DHCP Options for geolocation
values require an update of the entire location information (LI)
every time a client moves. Not all clients will move frequently,
but some will. Refreshing location values every time a client moves
does not scale in certain networks/environments, such as IP-based
cellular networks, enterprise networks or service provider networks
with mobile endpoints. An 802.11 based access network is one
example of this. Constantly updating LCI to endpoints might not
scale in mobile (residential or enterprise or municipal) networks in
which the client is moving through more than one network attachment
point, perhaps as a person walks or drives with their client down a
neighborhood street or apartment complex or a shopping center or
through a municipality (that has IP connectivity as a service).
If the client were provided a location URI reference to retain and
hand out when it wants or needs to convey its location (in a
protocol other than DHCP), a location URI that would not change as
the client's location changes (within a domain), scaling issues
would be significantly reduced to needing an update of the location
URI only when a client changes administrative domains - which is
much less often. This delivery of an indirect location has the
added benefit of not using up valuable or limited bandwidth to the
client with the constant updates. It also relieves the client from
having to determine when it has moved far enough to consider asking
for a refresh of its location.
"
I don't understand the statements above. IETF LCPs don't constantly update
endpoints with LCI. Just like dereferencing a uri, endpoints can reuse the
LCP mechanism to gain access to it's (newly changed) location. In both
mechanisms, LCP or URI deref, the location determination mechanism is
invoked by the LIS/LS at that time. I just don't get the proposed benefit.
What am I missing?
-Marc-
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
