Re: [Geopriv] Periodic location draft initial comments

["Mary Barnes" <[e-mail]>]

Hi Martin,

I appreciate the comments.  Responses are embedded below [MB].  

Thanks,
Mary. 

-----Original Message-----
From: Thomson, Martin [mailto:[e-mail]] 
Sent: Thursday, November 06, 2008 7:14 PM
To: Barnes, Mary (RICH2:AR00)
Cc: GEOPRIV
Subject: Periodic location draft initial comments

Hi Mary,

This is an interesting, and useful, draft that seems to pull a large
number of things together quite well.  I've read the draft through and
I'll save the in-depth comments for when I've had more time to think
about the problem, but I do have a few minor things.

There doesn't seem to be anything that discusses how measurements can be
acquired in batches.  Our experience with radio measurements is that
taking multiple measurements over a certain period is useful.  Some
discussion of how this might be done would be useful.  One option that
doesn't require any mechanism (in this draft) is to overload the
measurement definition to include multiplicity.  However, that doesn't
really fit with the definitions in the measurements draft.  My
preference is to add options to the measurement request so that
measurement acquisition can be batched somehow.  This probably needs
more thought though.
[MB] Yes, this seems to make sense. It was not one of the WiMAX
requirements AFAIK, but would seem to be something useful for them as
well. [/MB]

Regarding:
   For Devices that are made aware of location changes, the location
   change can be a trigger for the device to send another
   locationRequest message.
Strictly speaking, a device that is aware of location changes doesn't
need a LIS.  I'd suggest rewording this to place the emphasis on changes
in measurements:
   Devices that are able to take location-related measurements, might
   be able to use changes in measurement results to detect a potential
   change in location.  Changes in measurement data can be used as a
   trigger to make a location request.
[MB] This makes sense and I'll feed the suggestion back to WiMAX folks.
[/MB]                             

I struggled with section 5.1.  Partly, this is because I don't agree
that linking the expiration of a location URI with periodic requests for
measurements is the right thing to do.  This runs the risk of having the
location URI expire too quickly to be of use to anyone.  I really think
that adding a separate protocol parameter is the right way to do this.
Also, while the draft talks about the device driving the periodicity, it
doesn't actually attribute any intelligence to the device for the
decision to make a periodic request, which seems to me to be a little
backwards.  I'm probably not aware of all the context, so any pointers
would help.

[MB] I agree that it likely is far better to define a parameter for this
and that using the expiry likely isn't optimal - the original intent was
to support the periodicity on the Device side without any protocol
changes. But, if we can get agreement on making changes that optimize
the solution, that would certainly be better. [/MB]


(Not really a comment with this draft, but an observation in general.)
We (GEOPRIV) probably need to discuss the role of the LCP and the role
of presence in our architecture.  It's use cases like this that expose
how unclear that delineation is. 

General nit: In text, I prefer "location URI" and "location request" to
"locationURI" and "locationRequest"; English is nicer.
[MB] Okay. [/MB]

...and congratulations:  This draft actually managed to break the tools
HTML parser in its reference to the capabilities draft despite being
perfectly normal.

Regards,
Martin
------------------------------------------------------------------------
------------------------
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender immediately
and delete the original.  Any unauthorized use of this email is
prohibited.
------------------------------------------------------------------------
------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv