Document: draft-ietf-geopriv-loc-filters-10
Reviewer: Ben Campbell
Review Date: 9 March 2010
IESG Telechat date: 11 March 2010


Note: Since the IETF LC end-date and the telechat are only a day 
apart, I intend for this review to serve for both purposes.

Summary: 

This draft is almost ready for publication as a proposed standard, but there 
are issues that should be addressed first.

Major issues:

-- section 3.6, general:

As far as I can tell, this section creates a profile of the rate-control 
draft. You basically say use pieces of it, but make minor modifications to 
the normative requirements. Can you motivate why rate-control does not 
work as-is? And if it can't, perhaps this draft and that one should be 
harmonized prior to publication?

-- section 3.6, 2nd paragraph:

The empty notify language seems to conflict with the MUST level 
normative statement in rate-control that says:

> > 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.
> > 
Is it your intent to update rate-control to change this requirement? 
If so, it would be good to do so prior to publication of 
that draft. (see previous comment)



Minor issues:

-- general:

Some of the filter mechanisms in this draft require a lot of calculations 
for every candidate update to determine if it matches a filter.  It would 
be useful to have some discussion of the scalability impacts of this.

-- Section 1, paragraph 1, last sentence:

I assume their persistence ends when the associated subscription ends, right?

-- Section 3.2, first paragraph after figure 2:

It looks you've effectively declared the example as normative, and skipped 
over normative text that needs to be here. I find the "No other 
variant…" language confusing in context, as it's not clear to me 
what restriction in the example is constraining on <ns-binding>. I 
think you're better off treating the examples as informative, and 
fully defining the normative requirements in words. (Note that this 
applies for several instances where you say something to the effect 
of "an implementation MUST do FOO according to Figure X".)


-- section 3.6, first paragraph:

Why is average-rate left out? If you are going to suggest using just 
part of a previously defined mechanism, it would be nice to show 
motivation for the parts left out.

-- section 3.6, last paragraph:

I think you need more motivation for this use case. I _think_ you are 
referring to situations where, for example, a location service can give you 
increasing precision over time, and you want to say "give me the 
best you can in X seconds." But I'm afraid this could be misused in 
situations where the notifier requires some period of time to get 
_any_ information.

It would be helpful to have some comment on how filters interact 
with rate-control for location. For example, what happens if I 
have a max-interval that expires before a filter has been met? A trigger 
that fires before the min-interval expires? (I think the answer is 
that rate-control wins, but some text would be helpful.)


Nits/editorial comments:

-- General: 

I find the organization of this draft confusing. It would be helpful 
to have a clearer distinction between text that creates new mechanism or 
normative requirements, and text that describes how you can use 
existing mechanism. I think it would be easier to read if you separated 
new mechanism and usage of existing mechanisms into separate sections.

-- section 1, paragraph 1:

Please expand PIDF-LO on first mention. The expansion in the abstract 
doesn't count--the document should stand alone without the abstract.

s/technical/technically

"…alternative signaling approach…"  - Alternative to what? This wording 
makes it sound like sip-events is an alternative to 4119, which I 
don't think is what you mean to say.


-- Section 1, paragraph 2:

Do you mean to say "[the subscriber] not having to receive…", or "
without the notifier having to issue…"?

-- section 1, numbered list and preceding paragraph:

The list does not seem to follow from the preceding paragraph. That 
paragraph leads me to expect a list of mechanisms, and I think what 
I see is a list of problems to be solved.

-- section 3.6, first paragraph:

 Please clarify--do you mean "the implementation of only two attributes is 
required", i.e. you must not implement more than the two attributes, 
or "only the implementation of two attributes is required", meaning you 
don't have to implement more than the two attributes.



--idnits reports the following:

> >   Checking boilerplate required by RFC 5378 and the IETF Trust (see
> >   http://trustee.ietf.org/license-info):
> >   ----------------------------------------------------------------------------
> > 
> >   == You're using the IETF Trust Provisions' Section 6.b License Notice from
> >      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
> >      http://trustee.ietf.org/license-info/)
> > 
> > 
> >   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
> >   ----------------------------------------------------------------------------
> > 
> >      No issues found here.
> > 
> >   Checking nits according to http://www.ietf.org/id-info/checklist :
> >   ----------------------------------------------------------------------------
> > 
> >      No issues found here.
> > 
> >   Miscellaneous warnings:
> >   ----------------------------------------------------------------------------
> > 
> >   == The document seems to lack a disclaimer for pre-RFC5378 work, but was
> >      first submitted before 10 November 2008.  Should you add the disclaimer?
> >      (See the Legal Provisions document at
> >      http://trustee.ietf.org/license-info for more information.) -- however,
> >      there's a paragraph with a matching beginning. Boilerplate error?
> > 
> > 
> >   Checking references for intended status: Proposed Standard
> >   ----------------------------------------------------------------------------
> > 
> >      (See RFCs 3967 and 4897 for information about using normative references
> >      to lower-maturity documents in RFCs)
> > 
> >   == Unused Reference: 'GML' is defined on line 690, but no explicit
> >      reference was found in the text
> > 
> >   == Unused Reference: 'RFC3023' is defined on line 719, but no explicit
> >      reference was found in the text
> > 
> >   == Unused Reference: 'RFC4288' is defined on line 731, but no explicit
> >      reference was found in the text
> > 
> >   == Unused Reference: 'I-D.ietf-geopriv-http-location-delivery' is defined
> >      on line 746, but no explicit reference was found in the text
> > 
> >   -- Possible downref: Non-RFC (?) normative reference: ref. 'GML'
> > 
> >   ** Downref: Normative reference to an Informational draft:
> >      draft-ietf-geopriv-arch (ref. 'I-D.ietf-geopriv-arch')
> > 
> >   == Outdated reference: A later version (-08) exists of
> >      draft-singh-geopriv-pidf-lo-dynamic-07
> >