Subject: [Simple] Comments on draft-thomson-simple-cont-presence-val-req-00

From: Cullen Jennings <[email-masked]>
Date: Sat, 15 Nov 2008 15:49:25 -0700

I really liked this draft and hope that we proceed with solutions to  
some to these requirements.

One small thing, I think an example might help illustrate all the  
issues. I was trying to think of an example that illustrates many of  
the problems yet is not too complicated or too tied up in other  
controversial issues. Location seemed to complicated though it is  
probably the most important use case. The example that came to mind  
was imagine my communication device could measure my body temperature.  
This information is privacy sensitive, associated with user more  
though measured by device, continuous. It easy to imagine a sensor  
that could be within a 2 degree error in an almost instantaneously  
measurement seconds but needed to integrate for 45 seconds to get down  
to 0.0 degree error.  (Yah, yah, I know error is a big vague but  
forgive me that for now). It's easy to imagine some applications where  
1 degree is fine and there are others where one needs to be at the 0.1  
degree level. One could have applications that wanted to be notified  
if it went below 96 degrees fahrenheit or over 101 degrees. It easy to  
imagine applications that want it report once an hour.

The value based trigger section does not discuss the difficulties of  
how noisy measurement randomly bouncing above and below the threshold  
but this seems like it is often one of the issues.

On requirement V1. As you know, specifying ranges of multivariate  
values can get complicated. For multivariate values, I think it wold  
be sufficient to have an scheme where a min max value for for each  
variable was specified and any time any variable crossed one of these  
thresholds, an update was triggered.

Cullen in my individual contributor role

PS - This was a really nicely written draft. I read just about ever  
draft that was on a RAI agenda and this was probably the most coherent  
easy to understand draft I read. Thanks 
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 16 Nov 2008 10:24:15 -0600

Thanks Cullen,

All good suggestions.  I'll try to work out how to get them into the next revision.

I do have an example that is similar, but a little less...immediate.  I did some reading on the methods used to measure sulphur levels in petroleum - interesting stuff and subject to all the same constraints as here.  The temperature example has a better ring to it though.

Cheers,
Martin

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Saturday, 15 November 2008 4:49 PM
> To: [email-masked]
> Cc: Thomson, Martin
> Subject: Comments on draft-thomson-simple-cont-presence-val-req-00
> 
> 

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Sun, 16 Nov 2008 15:27:49 -0600

I second what Cullen has to say about the quality of the document -- 
this is very well written, and you have clearly put a lot of thought 
into it. It is an excellent basis for a requirements document for the 
filtering work in GEOPRIV, regardless of whether I am ultimately 
successful in convincing you of the appropriateness of presence for your 
application.

I'm also quite pleased to see that you've internalized the preponderance 
of the points I attempted to make in our earlier discussions on the 
issue. However, you appear to have what I believe are a couple of 
lingering misconceptions about the potential behavior that filters can 
exhibit. These are most vividly expressed in sections 4.3 and 4.4.

In particular, the document reflects a belief that the filter framework 
has inherent limitations that make it appropriate only for discrete 
properties. Key examples of this misconception are conveyed in the text:

> The hard, boolean nature of a filter is not tolerant of variation in 
> quality.
and:

> If filter documents are used as a medium for communicating watcher 
> preferences, the watcher could set a filter that only selects highly 
> accurate information, which could inadvertently suppress all 
> notifications.

As in our previous conversations, I suspect you have confused cause with 
effect. There is nothing inherent in the filter framework that imposes 
or implies such limitations. What you are observing is a consequence of 
the fact that event packages so far have all been composed exclusively 
of discrete values -- not the *reason* that they have.

When GEOPRIV sets off to define the filter extensions that relate to 
location, they may elect to define them to have the useless (or, at 
best, infuriatingly limited) properties you describe in these excerpts. 
I will repeat my earlier advice on this topic: don't.

You are far more studied in the nature of the information a watcher 
would want to convey regarding the quality of information it receives 
from an LIS, so I won't even try to come up with an example of the 
parameters that need to be conveyed. However, if you can give an example 
of what a watcher would want to say, I'll happily format it into a 
plausible syntax for a filter, and provide the narrative that explains 
the semantics.

/a

On 11/15/08 4:49 PM, Cullen Jennings wrote:
> easy to understand draft I read. 
> Thanks_______________________________________________
> Simple mailing list
> [email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 16 Nov 2008 23:41:47 -0600

I think that you've drawn on the one major aspect of the draft that I was almost immediately unhappy with.  As you point out, I was probably suckered by the existing examples, which interpreted in isolation paint a very specific picture that doesn't cover this use case.

I think that the types of things you are looking to convey for location are described in my location-quality draft [1].  One important aspect of this is the way that (as described in the draft), you might like uncertainty of 50m, you might settle for less.  I'd like your opinion on how quality "targets" fit into the RFC 4661 schema.  Maybe the sit in a new top-level item alongside <what> or <trigger>.

[1] http://tools.ietf.org/html/draft-thomson-geopriv-location-quality-01

> From: Adam Roach [mailto:[email-masked]]
> Sent: Sunday, 16 November 2008 3:28 PM
> To: Cullen Jennings
> Cc: [email-masked]; Thomson, Martin
> Subject: Re: [Simple] Comments on draft-thomson-simple-cont-presence-
> val-req-00
>