Subject: [Geopriv] draft-ietf-geopriv-loc-filters-11

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 27 Mar 2010 16:12:20 -0700

Hi Dan,

please take a look at the new version. Based on your feedback we have

* updated the examples and added clarifying text
* modified the text around the <ns-bindings>
* updated the abstract
* updated the Figure 9  to make the example easier to understand.

Ciao
Hannes

----

Discuss (2010-03-11)
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 <ns-bindings> 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 <trigger> and
<changed> elements).

Comment (2010-03-11)
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.