> From section 1:
>
>" 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.
weeellll -- if you want cubical or office level accuracy/resolution,
or if you want to know which floor you are on (all from the
perspective of the device), where devices move frequently - either
you update the location (e.g., this particular DHCP Option 99/123))
often (probably at certain intervals) via a push from the LIS/DHCP
server, or your client requests updated Option 99/123 whenever it
detects it has moved.
Either way - there is LI being transmitted frequently, but only if
either end (client or server) is configured to do this.
Conversely, if your client only asks for a Location URI, you don't
have (however often you move or the network updates your location)
repeated LCI pushes or pulls, which take up BW.
The point of this document is optimization of location delivery. Get
the URI Option once, and you don't (really) need an update to the
Option until your client changes admin domains due to moving outside
of Starbucks' dot11 coverage area and into Joe's Pizza shop and ISP
coverage area, for example.
Do you believe this optimization makes sense?
Do you believe this optimization makes sense, but needs to be written
more clearly?
Or, do you believe Location URIs don't make sense?
James
>What am I missing?
>
>-Marc-
>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
