[Top] [All Lists]

Re: Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-filters-10

2010-03-21 13:10:16
Hi Hannes,

Thanks for the response. Comments inline. I deleted sections that I believe to 
be resolved.



On Mar 21, 2010, at 10:34 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

Hi Ben, 

Thanks for your detailed review. Please find my response inline. 
An updated version of the draft will be submitted in the next few days. 

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
Behalf Of ext Ben Campbell
Sent: 09 March, 2010 18:00
To: Rohan Mahy; Brian Rosen; Hannes Tschofenig; General Area 
Review Team
Cc: Cullen Jennings; IETF-Discussion list
Subject: Gen-ART LC/Tekechat Review of 

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see

Please wait for direction from your document shepherd or AD 
before posting a new version of the draft.

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.


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?

I don't believe that we introduce modifications to rate-control. 

It seems to me that this draft _does_ modify it. On reflection, my comment here 
is merely a summary of the more concrete comment below, so I'll address it 

-- 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)

I tried to clarify the sentence. In the use cases we consider it is
quite likely that location information is not available at the time the
subscription request was received and then the returned state
corresponds to an empty notification. 

I understand the reasoning behind it. My main concern is that you are 
recommending something that is normatively prohibited in rate-control. There's 
a few ways to handle that:

1) Treat rate-control as an informative reference, and say you're doing 
something mostly like rate control, but not quite identical. That would require 
quite a bit more normative language to describe what you're actually doing.

2) Make this draft update rate-control to allow for empty bodies when you don't 
have location info yet. Put some tightly constrained language around it. so 
that this doesn't become a _general_ udpate.

3) Since rate-control has, to my knowledge, not been pubreq'd yet, try to get 
the authors to modify the language to allow for empty bodies for this use case.

I personally think 3 is the best path forward, as I think the empty notify is 
generally useful for rate-control, and implementor are likely to do it anyway.


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.

I agree with you that some of the filtering operations require a fair
amount of calculations and location determination to happen in order to
have real-time access to location information. 

We did not address scalability considerations in the document and we
would rather like to postpone detailed investigations once we gain some
implementation and deployment experience. If such scalability concerns
indeed arise we are happy to fix them with an update to the document but
we believe that it will take a fair amount of time to reach maturity
before we can make good measurements. 

I did not mean to suggest a full analysis. Just a mention that implementors 
should think about this and use reasonable care. But my feelings are not strong 
here--if, after thinking about it, you still don't think it belongs in this 
draft, I'm okay with that.

The approach is a bit similar to what you see other groups doing in the
IETF with the work on presence scalability. There, the specifications
got implemented and deploymend and only some time later investigations
are made regarding scalability with the available deployment experience.

I'm not sure I'd hold that example up as ideal process :-) 

-- 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.

We don't think that there is anything wrong with implementing rate
control but we could not find a use case for the average-rate feature
for our application domain. 

A sentence to that effect would be helpful.


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.)

I believe that these aspects should be explained in rate control because
it is not specific to this document.  

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.

Interesting comment. I actually thought that an implementer would not
care about this distinction but would rather be interested in how to
accomplish the functionality overall. I had written the document
intentionally with such a focus. 

Okay--this is really more of a difference of opinions on a style question, so 
I'll withdraw the comment.


--idnits reports the following:

 Checking boilerplate required by RFC 5378 and the IETF Trust (see


 == 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

 Checking nits according to


    No issues found here.

 Checking nits according to :


    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 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

Ietf mailing list

Ietf mailing list