I guess my confusion comes from the section I pulled out as it talks about
LCI, which is only offered to a target. Also, I'm not aware that either
DHCP or HELD are capable of a 'push'. So, I'm not seeing the added value in
a target dereferencing a URI to get LbyV vs. performing additional LCP LbyV
queries. In either case, the target does a 'query'.
Is this section stating the LbyR handed out via the LCP is a SIP sub/notify?
I understand the value of a URI when someone other than the target is
wanting location.
Am I making any sense?
-Marc-
On 3/25/10 4:14 PM, "James Polk" <jmpolk@cisco.com> wrote:
> At 08:28 AM 3/25/2010, Marc Linsner wrote:
>> 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
