Filtering Location Notifications in the Session Initiation Protocol (SIP)
draft-ietf-geopriv-loc-filters-11

[Ballot comment]
===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.

is a typo

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

[Ballot comment]
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  element is a child of the
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
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.

[Ballot discuss]
The DISCUSS and COMMENT issues are based on input from Dale Worley.

The following items are problematic as they point to ambiuities in the specification:

1. Section 3.3, element value changes:  In the example, changes in the
subordinate civic address components "A1", "A2", etc. will cause a
trigger, but changes in "country" will not.  This is probably
unrealistic; in a realistic application, a trigger on one civic
address component would be or'ed with triggers on each higher-level
civic address component.

2. Section 3.3, element value changes:  The statement "An
implementation MUST support the functionality as shown in Figure 3
with  replacing the prefix.  No other variant is
supported." is nowhere near clear enough to be a specification.  In
particular, the uses in figures 4 and 5 are clearly distinguishable
from the use in figure 3 (based on the number of  and
elements).

[Ballot comment]
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/

[Ballot discuss]
This is a good document and I was ready to ballot Yes. However, like
other reviewers I had trouble with the normative requirements. In my
case Section 3.3 said:

  An implementation MUST support the functionality as shown in Figure 3
  with  replacing the prefix.  No other variant is
  supported.

I do not understand what to implement based on this. In particular,
Section 3.3 has also Figure 4 that shows another variant. Is only the
first one required to be supported? What exactly does "MUST support
this example snippet of XML" mean?

[Ballot comment]
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.

[Ballot discuss]
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns
  that ought to be addressed before this document is approved, and I have
  summarized them below.
 
  (1) Section 3.6 seems to create a profile of the rate-control
      document, but minor modifications to the normative requirements
      are made.  Can you motivate why rate-control does not work as-is?
      If not, perhaps the two documents should be harmonized.

  (2) The empty notify language in the 2nd paragraph of Section 3.6
      seems to conflict with the MUST statements in rate-control
      document:
      >
      > ... depending on the event package and subscriber
      > preferences indicated in the SUBSCRIBE request, the NOTIFY request
      > MUST contain either the current full state or the partial state
      > showing the difference between the current state and the last
      > successfully communicated state.
      >
      This also indicates that the two documents should be harmonized.

  (3) In Section 3.2, first paragraph after figure 2, the text effectively
      declares the example as normative, but fails to offer normative text.
      Also, the "No other variant" language is confusing; it is not clear
      what restriction in the example is constrains .  Please
      make the examples informative and provide normative text.

[Ballot comment]
These are very small nits:

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

is a typo

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

[Ballot discuss]
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.

[Ballot comment]
Non-blocking comments:

Section 3.1., paragraph 1:
>    The  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 .)


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/

[Ballot discuss]
Section 9.1., paragraph 2:
>    [I-D.ietf-geopriv-arch]
>              Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
>              Tschofenig, H., and H. Schulzrinne, "An Architecture for
>              Location and Location Privacy in Internet Applications",
>              draft-ietf-geopriv-arch-01 (work in progress),
>              October 2009.

  DISCUSS: Downref: Normative reference to an Informational draft:
  draft-ietf-geopriv-arch (ref. 'I-D.ietf-geopriv-arch'). Didn't see it
  called out in the IETF LC.

[Ballot comment]
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  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  filters to ensure
  you are notified when any of the element values change.

In the last sentence: do you mean something like:

     
         
              //ca:A1
         
         
              //ca:A2
         
         
              //ca:A3
         
         
              //ca:PC
         
     

instead of:

     
         
              //ca:A1
              //ca:A2
              //ca:A3
              //ca:PC
         
     

?

3.5.  Location Type:

 
 
     
         
                geodetic

Are leading spaces insignificant in this case?

             
         
     
 

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following assignment
in the "ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
-- --- --------------------- ---------
location-filter urn:ietf:params:xml:ns:location-filter location-filter
[RFC-geopriv-loc-filters-09]


Action 2:

Upon approval of this document, IANA will make the following assignment
in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
-- --- -------- ---------
location-filter urn:ietf:params:xml:schema:location-filter location-filter
[RFC-geopriv-loc-filters-09]


We understand the above to be the only IANA Actions for this document.

The GEOPRIV working group requests publication of draft-ietf-geopriv-
loc-filters-09 as Proposed Standard.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Richard Barnes. The
Shepherd has personally reviewed this version of the document, and
believes it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been the subject of thorough discussion within the
GEOPRIV and SIMPLE working groups. I have no concerns about the level
of review this document has received.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not believe that this document requires any special review. It
does contain XML schemas, but the structures it defines are simple and
have been reviewed by members of the working group with XML expertise.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no special concerns about this document. There have been no
IPR disclosures related to the document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is fairly wide consensus in the working group that this document
is a useful and usable way to encode geolocation-based event filters.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of any extreme discontent or potential appeals related
to this document.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have verified that the the document satisfies all ID nits, with the
exception of some reference problems discussed below.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative, but need some
clean-up (which can be rolled in with responses to last-call and IESG
comments). There is one downref, a normative reference to an
Informative document, which I believe can be made into an informative
reference.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and provides instructions for
IANA to register a new XML schema and namespace.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document contains two XML schemas and several example XML
documents. I have validated that these XML structures are well-formed
using the W3C automated validator ().

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes filters that limit asynchronous location
notifications to compelling events, designed as an extension to RFC
4661, an XML-based format for event notification filtering, and based
on RFC 3856, the SIP presence event package. The resulting location
information is conveyed in existing location formats wrapped in the
Presence Information Data Format Location Object (PIDF-LO).


Working Group Summary

There is consensus in the working group that the policies described
this document are a useful way to transmit geolocation-based event
filters.


Document Quality

The document has been reviewed by key participants from the GEOPRIV
working group.