Carl
> FWIW, I like this, including the note.
>
> Brian
>
>
> On 10/20/09 7:55 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
>
>> Hi Hannes,
>>
>> Thanks for the update. It looks like you got all the comments, bar this
>> one:
>>
>>>> Section 3.4: It's unclear what the effect of uncertainty is on
>>>> this. An implementation is asked to make a Boolean decision,
>>>> but not given the necessary tools to ensure that the decision
>>>> it makes is the one that is expected.
>>
>> This is one of the issues I thought worth looking at. Is it necessary
>> for
>> interoperability that we define how a notifier/PA determines that a
>> location
>> containing uncertainty is inside or outside a particular region.
>>
>> I'd like to see a simple statement to the effect:
>>
>> If the Target was previously outside the region, the notifier sends a
>> notification when the Target's location is within the region with at
>> least 50%
>> confidence. Similarly, when a Target starts within the region, a
>> notification
>> is sent when the Target's location moves outside the region with at
>> least 50%
>> confidence.
>>
>> I'll let you decide if you want to include this extra explanatory
>> information:
>>
>> Note that having 50% confidence that the Target is inside the area
>> does not
>> correspond to 50% outside. Confidence that the location is within the
>> region,
>> plus confidence that the location is outside the region cannot be 100%.
>> The
>> total confidence depends on the confidence in the original location,
>> which is
>> always less than 100% (95% is recommended in [RFC5491]). The benefit of
>> this
>> is that notifications are naturally limited: small movements at the
>> borders of
>> the region do not trigger notifications.
>>
>> c.f.
>> <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-03#section-4.3>
>>
>>
>>> -----Original Message-----
>>> From: Tschofenig, Hannes (NSN - FI/Espoo)
>>> [mailto:hannes.tschofenig@nsn.com]
>>> Sent: Wednesday, 21 October 2009 3:50 AM
>>> To: Thomson, Martin; Alissa Cooper; GEOPRIV
>>> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06
>>>
>>> Hi Martin,
>>>
>>> I believe I have addressed your comments and I have also added some
>>> further text to constraint the functionality in the document further to
>>> avoid interoperability problems.
>>>
>>> Here is the latest version that I plan to submit:
>>> http://www.tschofenig.priv.at/svn/Filters/draft-ietf-geopriv-loc-
>>> filters
>>> -07.txt
>>>
>>> Ciao
>>> Hannes
>>>
>>>> -----Original Message-----
>>>> From: geopriv-bounces@ietf.org
>>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of ext Thomson, Martin
>>>> Sent: 13 October, 2009 06:01
>>>> To: Alissa Cooper; GEOPRIV
>>>> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06
>>>>
>>>> In my opinion, this document is ready for publication.
>>>>
>>>> I have a few very minor issues, and a bunch of nits. None of
>>>> these are so important that they need to be fixed immediately.
>>>>
>>>> I'm sure that Rohan's affiliation has changed. Last time I
>>>> saw him it certainly wasn't Plantronics.
>>>>
>>>> Title: The "reporting" aspect was long ago removed. I'd
>>>> propose simply:
>>>> Filtering Location Notifications in Presence No need to
>>>> mention PIDF-LO. There might be a need to mention SIP, in
>>>> which case it becomes
>>>> Filtering Location Notifications in Session Initiation
>>>> Protocol (SIP) Presence
>>>>
>>>> Section 1, OLD:
>>>> RFC 3265 can be used with so-called 'filters'...
>>>> NEW:
>>>> SIP events [RFC3265] can be used with filters...
>>>>
>>>> Q: what is "so-called" about them? Is the term not defined in
>>>> RFC 4660? This phrase has negative connotations. (I suspect
>>>> that this is symptomatic of Rohan's views on the filtering
>>>> docs. Not undeserved, but also unnecessary.)
>>>>
>>>> Section 1: Is it worth stating in the introduction that this
>>>> document mixes new mechanisms with documentation of existing
>>>> mechanisms?
>>>>
>>>> Section 1: wayward apostrophe: s/presence event
>>>> package'/presence event package/
>>>>
>>>> Section 3.*: Suggest a better namespace prefix to use in
>>>> examples might be "lf:" rather than the generic "ext:".
>>>>
>>>> Section 3.4: It's unclear what the effect of uncertainty is on
>>>> this. An implementation is asked to make a Boolean decision,
>>>> but not given the necessary tools to ensure that the decision
>>>> it makes is the one that is expected.
>>>>
>>>> Section 3.5:
>>>> For the example above, if the 'exact' attribute was "true", then
>>> the
>>>> only possible response is either a "civic" location or an error
>>>> message.
>>>> What does it mean to provide an "error message" in the context
>>>> of being unable to provide the requested location type? In
>>>> this case, I'd suggest:
>>>> s/or an error message./or no location information./
>>>>
>>>> Section 3.6: (This is recent text, so this is actually the
>>>> first time that I've read it.) No specific comment here
>>>> (aside from a wayward period.). However, the example does
>>>> look a little like a wall of text. I can see several
>>>> paragraphs there. Perhaps if this "example" was split into a
>>>> sub-section, there wouldn't be a tendency to try to create the
>>>> ultimate paragraph.
>>>>
>>>> Section 5: I don't think that the third bullet is necessarily
>>>> true. This document doesn't really build in PIDF-LO, but it
>>>> does depend on its format. If, in that fact, there are
>>>> security considerations, I'm not aware of them.
>>>>
>>>> Section 5: Is it worth noting that there are no policies that
>>>> dictate what filters may be used? I tend to object to live
>>>> tracking as a general rule, but am offered no means to control
>>>> this behaviour by watchers (I can tell them not to get
>>>> location, even black out certain areas, but not limit rates).
>>>> Are we satisfied that this document leans on the "local
>>>> policy" crutch in this area?
>>>>
>>>> --Martin
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>>>>> Behalf Of Alissa Cooper
>>>>> Sent: Tuesday, 13 October 2009 2:58 AM
>>>>> To: GEOPRIV
>>>>> Subject: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06
>>>>>
>>>>> This is a GEOPRIV Working Group Last Call for comments on
>>>>> draft-ietf-geopriv-loc-filters-06
>>>>> (http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-06)
>>>>>
>>>>> Please send your comments no later than Monday, November 2, 2009.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> Geopriv@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>
>>>> ---------------------------------------------------------------
>>>> ---------------------------------
>>>> 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
>>>> Geopriv@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
