RE: [GeoPriv]: Review comments on HELDdraft: http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-03

["Roger Marshall" <RMarshall at telecomsys.com>]

Barbara:
Device-to-LIS interoperation can take many forms.

If a LIS provides a Device's location when queried (by an element) and
interacts with the Device each time, then I agree there is no inherent
offloading of work.

If, on the other hand, a Device interacts with the LIS on a periodic
basis which results in a location update, then in turn makes that
location information available to any authorized requestor, then that
does show a case whereby the LIS sheds some load from the Device.

I don't think its necessary to introduce a Presence server into the
above equation, though I admit that one might be used in a solution.  A
'watcher' application might go through another level of indirection,
such as a HTTP location app. server, as is the case for typical "Friend
Finder" services, each of these have a Presence server component
somewhere.

The original objection was against the following terminology:
> "The LIS exists because not all Devices are capable of
>    determining LI, and because, even if a device is able to determine
>    its own LI, it may be more efficient with assistance." 

While the above statement is true wrt increased efficiency of location
determination, that is not the sole reason that a LIS exists.  Even if
all Devices *could* do self-location-determination, a LIS would still be
valuable for the reasons, including the distribution of load due to the
Device not being in a radio coverage area, not being powered up, or not
being willing to accept a direct query.

As to the idea that a LIS caches location, maybe it does or maybe it
doesn't - probably depends on the type of LIS and caching (storing) has
a range of values, from something transitory to something infinite.

-roger marshall.  

> the only way that the LIS could be used to alleviate load 
> from the target device, is for the device to give out the 
> (unsecured) location URI. Since we haven't defined a way for 

> -----Original Message-----
> From: Stark, Barbara [mailto:bs7652 at att.com] 
> Sent: Tuesday, December 11, 2007 12:39 PM
> To: Mary Barnes; Roger Marshall; geopriv at ietf.org
> Subject: RE: [GeoPriv]: Review comments on HELDdraft: 
> http://tools.ietf.org/html/draft-ietf-geopriv-http-location-de
> livery-03
> 
> Mary,
> I agree with your replies to Roger's comments. You asked for 
> feedback on the following:
> --------- snipped text of Roger's comment C7 and Mary's 
> response ------ C7. Section 3, pp1., s4.  Change wording. 
> Change from: 
> "The LIS exists because not all Devices are capable of
>    determining LI, and because, even if a device is able to determine
>    its own LI, it may be more efficient with assistance." 
> Change to: 
> "The LIS exists because not all Devices are capable of
>    determining LI, and because, even if a device is able to determine
>    its own LI, it may be more efficient with assistance, and 
> finally, because it may be desired that external requests for 
> a target location be cached in a LIS in order to alleviate 
> load from the target device."
> 
> Reason: The reason given as to why a LIS exists needs to be 
> expanded to cover the idea of "storing location". 
> 
> [MB] I would like more WG feedback on this.  By definition, 
> the LIS caches location information, but it was not my 
> understanding that alleviating load on the target was a 
> motivation.  [/MB] --------------end snipped 
> text-------------------------------
> 
> In the current HELD draft, we only have the source IP address 
> as the identifier. Without extensions to support other IDs, 
> the only way that the LIS could be used to alleviate load 
> from the target device, is for the device to give out the 
> (unsecured) location URI. Since we haven't defined a way for 
> the LIS to be populated with security rules for who can 
> dereference location, I think it would be a bad idea for us 
> to encourage this use, or claim that it is desirable in some way.
> Therefore, I don't agree with adding this function to the description.
> 
> To me, alleviating load from the target is more what I would 
> expect from a Presence Server. There's nothing that would 
> stop a server that has LIS functionality on it, from also 
> being a SIP Presence server. Within the definition of 
> Presence Server, we know how to do security and all sorts of 
> URIs, including long-lasting ones, like SIP user IDs or IMS PUIDs.
> Let's not change the definition of LIS to somehow also 
> incorporate the definition of a presence server.
> Barbara 
> 
> *****
> 
> The information transmitted is intended only for the person 
> or entity to which it is addressed and may contain 
> confidential, proprietary, and/or privileged material. Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is 
> prohibited. If you received this in error, please contact the 
> sender and delete the material from all computers. GA623
> 
> 
> 


CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.



_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv