Filtering Location Notifications in the Session Initiation Protocol (SIP)
RFC 6447

Note: This ballot was opened for revision 11 and is now closed.

(Cullen Jennings) (was Yes) Discuss

Discuss (2010-03-08 for -)
AD needs to review LC comments

(Jari Arkko) (was Discuss) Yes

(Robert Sparks) (was No Objection, Discuss) Yes

Comment (2010-04-02)
No email
send info
===Comments below pertained to -10 and have been addressed===

Section 3.6 should be more clear on whether it is restricting the use of all the mechanics in event-rate-control, or only noting which of those mechanics need to be used to achieve the purpose addressed in this draft. In particular, I suggest changing "The implementation of only these two attributes" to "The use of only these two attributes".

Ben Campbell's genart review comments are related.

These are very small nits:

2nd paragraph of 3.3 would read more correctly if you said A1, A2, A3 _and_ PC change.

<changes> is a typo

The labels for figure 3 and 4 are wrong - should say Element Value Change Example

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Gonzalo Camarillo) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-03-09)
No email
send info
Non-blocking comments:

Section 3.1., paragraph 1:
>    The <moved> element MUST contain a value in meters indicates the
>    minimum distance that the resource must have moved from the location
>    of the resource since the last notification was sent in order to
>    trigger this event.  Note that the condition could be met by a change
>    in any axis including altitude.

  But surely not only by change along a single axis, right? (I think
  what you mean is that the length of the vector between the two points
  is longer than <moved>.)

Section 5.2.3, paragraph 1:
>    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.

  Why 50%? Why not 30 or 70%? (Magic number.)

Section 5.2.3, paragraph 2:
>    Note that having 50% confidence that the Target is inside the area
>    does not correspond to 50% outside.  The confidence that the location
>    is within the region, plus the confidence that the location is
>    outside the region is limited to the confidence of the location.  The
>    total confidence depends on the confidence in the 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.

  Whether the last sentence is true depends entirely on how accurate the
  positioning is compared to the movement.

Section 9., paragraph 0:
> 9.  References

  idnits reports several unused references, including normative ones.

Section 3.3., paragraph 5:
>    In times where it is desireable to know if any one element of a list

  Nit: s/desireable/desirable/

(Adrian Farrel) No Objection

Comment (2010-03-11 for -)
No email
send info
I found the second paragraph of Section 1 hard to parse

   The frequency of notifications necessary for various geographic
   location applications varies dramatically.  The subscriber should be
   able to get asynchronous notifications with appropriate frequency and
   granularity, without having to issue a large number of notifications
   that are not important to the application.

The second sentence appears to mix "getting" notifications with "issuing" notifications. Are you attempting to distinguish asynchronous notifictations from requst/response transactions?


Nit of the smallest type

Section 1
s/that allows the number/that allow the number/

(Russ Housley) (was Discuss) No Objection

Comment (2010-03-10)
No email
send info
  The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns
  that are not included in my DISCUSS position.  Please consider them.

(Alexey Melnikov) No Objection

Comment (2010-03-05 for -)
No email
send info
3.3.  Element Value Changes

   Figure 3 shows an example where a notification is sent when the civic
   address tokens A1, A2, A3, or PC change (all 4 must change in order
   to let the <trigger> element evaluate to TRUE).  In times where it is
   desireable to know if any one individual of a list of CAtypes change,
   then they have to be put into separate <changes> filters to ensure
   you are notified when any of the element values change.

In the last sentence: do you mean something like:

       <filter id="123" uri="">

instead of:

       <filter id="123" uri="">


3.5.  Location Type:

   <?xml version="1.0" encoding="UTF-8"?>
       <filter id="123" uri="">
               <lf:locationType exact="true"> geodetic

Are leading spaces insignificant in this case?


(Tim Polk) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2010-03-11)
No email
send info
1. The draft could use a careful editing for English usage.  Some
problems are simple statement structure (e.g., "This document defines
a new event filters and describes others using existing mechanisms
that may be relevant to a subscriber in the context of location
filtering:" does not grammatically connect to the following list).
Other problems leave out information (e.g., the text of section 3.1
does not state that the <moved> element is a child of the <trigger>
element, although the example makes that clear).

2. Section 3.2, speed changes:  The statement "An implementation MUST
support the functionality as shown in Figure 2 with <ns-bindings>
replacing the prefix.  No other variant is supported." is nowhere near
clear enough to be a specification.

3. Section 3.6, rate control:  It might be useful to provide a more
extended example than figure 9, one that shows the initial SUBSCRIBE
and NOTIFY, and the subsequent SUBSCRIBE that lengthens the
max-interval value.

Magnus Westerlund No Objection