Subject: [Gen-art] Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-filters-10

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Mar 2010 16:59:58 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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.

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
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 21 Mar 2010 19:34:16 +0200

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: [email-masked] [mailto:[email-masked]] 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 
>draft-ietf-geopriv-loc-filters-10
>
>Please wait for direction from your document shepherd or AD 
>before posting a new version of the draft.
>
>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?
>

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

>The empty notify language seems to conflict with the MUST 
>level normative statement in rate-control that says:
>
>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. 

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

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.

>subscription ends, right?
Correct. I extended the sentence. 

>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".)
>
Changed the text according to your suggestion. 

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

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

I have added a pointer to Section 6.1 of the HELD specification
referring to the fucntionality of the responseTime parameter where this
functionality came from.

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

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

OK. 

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

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

Fixed. 

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

OK. Fixed. 

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

Ciao
Hannes

>>   Checking nits according to 
>http://www.ietf.org/ietf/1id-guidelines.txt:
>>   
>> 
>>   == Unused Reference: 
>'I-D.ietf-geopriv-http-location-delivery' is defined
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Ben Campbell <[email-masked]>
Date: Sun, 21 Mar 2010 11:08:35 -0700

Hi Hannes,

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

Thanks!

Ben.

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

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

[...]

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

> are made regarding scalability with the available deployment experience.

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

> for our application domain. 

A sentence to that effect would be helpful.

[...]

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

[...]

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 22 Mar 2010 06:12:21 +0800

Ben wrote:
> There's a few ways to handle that:
>

I was not under the impression from reading rate-control that that document was modifying 3265 to prevent notifiers from sending an empty notify.  But, your suggestion is a reasonable one.  Reading the rate-control text you quoted earlier in the thread could lead to the impression that this is the case.  I've added the rate control authors to the thread.

--Martin

---

From: Ben Campbell <[email-masked]>
Date: Sun, 21 Mar 2010 15:22:55 -0700

> I was not under the impression from reading rate-control that that document was modifying 3265 to prevent notifiers from sending an empty notify.  But, your suggestion is a reasonable one.  Reading…

I don't think it modifies 3265 in general, but it does seem to normatively prevent empty NOTIFY requests as a result of a max-interval expiration.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 22 Mar 2010 00:24:39 +0200

If rate-control gives the impression that it disallows empty NOTIFYs to
be sent then rate-control needs to change. If location is not available
at the time when the SUBSCRIBE hits the location server then the server
just cannot send something.

Do you agree with me? 

>From: ext Ben Campbell [mailto:[email-masked]] 
>Sent: 21 March, 2010 18:23
>To: Thomson, Martin
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]; 
>[email-masked]; [email-masked]; 
>Cullen Jennings; Rohan Mahy; IETF-Discussion list; General 
>Area Review Team; Hannes Tschofenig
>Subject: Re: Gen-ART LC/Tekechat Review of 
>>> 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.
>> 
>> I was not under the impression from reading rate-control 
>that that document was modifying 3265 to prevent notifiers 
>from sending an empty notify.  But, your suggestion is a 
>reasonable one.  Reading the rate-control text you quoted 
>earlier in the thread could lead to the impression that this 
>is the case.  I've added the rate control authors to the thread.
>> 
>
>I don't think it modifies 3265 in general, but it does seem to 
>normatively prevent empty NOTIFY requests as a result of a 
>max-interval expiration.
>
>> --Martin
>
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 22 Mar 2010 06:29:19 +0800

> I don't think it modifies 3265 in general, but it does seem to normatively prevent empty NOTIFY requests as a result of a max-interval expiration.

Agreed.  Some clarification on this point would be useful.

---

From: Ben Campbell <[email-masked]>
Date: Sun, 21 Mar 2010 15:31:17 -0700

> just cannot send something.

We're not talking about NOTIFYs sent in response to a SUBSCRIBE. We're talking about NOTIFY's sent as a result of a max-interval expiration, when using the rate-control mechanism.  The rate-control draft requires content in that situation, and the geopriv-loc-filters draft recommends empty notifies in the same situation.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 22 Mar 2010 06:49:05 +0800

So, the rate control does recognize that the first notify message can be empty or might not contain all state:

   $3.2:  Thus, the first notification might be empty, or certain values might be absent.

The text that was originally quoted, that we're discussing is this:

   A compliant notifier MUST generate notifications whenever the time
   since the most recent notification exceeds the value in the "max-
   interval" parameter.  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.

The second sentence, taken out of context might be interpreted as Ben did - a blanket prohibition on empty notify messages.  Reading through again, with complete context, I'm not sure that I agree with this assessment.  If the rate-control editors are amenable to a clarification in this section, it would be nice, but I don't see it as necessary.

--Martin
________________________________________
From: Ben Campbell [[email-masked]]
Sent: Sunday, 21 March 2010 3:31 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: Thomson, Martin; [email-masked]; [email-masked]; [email-masked] Loreto; Cullen Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team; Hannes Tschofenig; [email-masked]; Adam Roach
Subject: Re: Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-filters-10

---

From: Ben Campbell <[email-masked]>
Date: Sun, 21 Mar 2010 16:09:25 -0700

> The second sentence, taken out of context might be interpreted as Ben did - a blanket prohibition on empty notify messages.  Reading through again, with complete context, I'm not sure that I agree…

i did not take it to be blanket prohibition on empty NOTIFY requests. I took it to be a prohibition against empty NOTIFY requests sent as a result of the expiration of a max-interval parameter. The language I objected to in the location filter draft seemed to explicitly suggest empty notifies as a result of max-interval parameter.

Here's the language I refer to, in section 3.6, last sentence of paragraph 1 and first sentence of 2:

>    [...] Whenever the time since the
>    most recent notification exceeds the value in the "max-interval"
>    parameter, the current state would be sent in its entirety, just like
>    after a subscription refresh.
> 
>    If complete state is not immediately available, then an empty NOTIFY
>    is sent immediately and subsequently a separate NOTIFY containing
>    location is generated some time between the time included in 'min-
>    interval' and the time in 'max-interval'.  An important use case for
>    location based applications focuses on the behavior of the initial
>    NOTIFY message(s) and the information it returns, for example in case
>    of emergency call routing.  When an initial NOTIFY is transmitted it
>    might not include complete state.

Although the last couple of sentences talk about, I read the first part as suggesting that if state is not available when a max-interval expires, you should send an empty NOTIFY.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sat, 27 Mar 2010 05:51:58 +0800

(dropping [email-masked])

So I'd like to close this, so I'll summarize and propose an action:

Question:  max-interval expires, is it permitted for a notifier to generate an empty notify?

Position:  This is NOT desirable behaviour.  A notifier has advance warning that it needs to generate state and can do so.  I don't actually see a need to support empty notifications once the subscription is established and the notifier is providing state.  It's only going to lead to unexplained holes.

Text: (for loc-filters, no change to rate-control)

OLD:
   If complete state is not immediately available, then an empty NOTIFY
   is sent immediately and subsequently a separate NOTIFY containing
   location is generated some time between the time included in 'min-
   interval' and the time in 'max-interval'.  An important use case for
NEW:
   Immediately after the creation of a subscription, 
   if complete state is not immediately available, then an empty NOTIFY
   is sent immediately.  A separate NOTIFY containing
   location is subsequently generated some time between the time included in 'min-
   interval' and the time in 'max-interval'.  An important use case for

I think that this addresses the problem.  Whether or not this was the original intent of the authors, we didn't really discuss this particular wrinkle.

--Martin

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Sunday, 21 March 2010 4:09 PM
> To: Thomson, Martin
> [email-masked]; [email-masked] Loreto; Cullen
> Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team;
> Hannes Tschofenig; [email-masked]; Adam Roach
> > The second sentence, taken out of context might be interpreted as Ben
> did - a blanket prohibition on empty notify messages.  Reading through
> again, with complete context, I'm not sure that I agree with this
> assessment.  If the rate-control editors are amenable to a
> clarification in this section, it would be nice, but I don't see it as
> necessary.
> >
> 
> i did not take it to be blanket prohibition on empty NOTIFY requests. I
> took it to be a prohibition against empty NOTIFY requests sent as a
> result of the expiration of a max-interval parameter. The language I
> objected to in the location filter draft seemed to explicitly suggest
> empty notifies as a result of max-interval parameter.
> 
> Although the last couple of sentences talk about, I read the first part
> as suggesting that if state is not available when a max-interval
> expires, you should send an empty NOTIFY.
> 
> 
> 
> 
> 
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 26 Mar 2010 15:06:41 -0700

I think it's almost there. The problem seems to come from the last sentence in the previous paragraph:

> Whenever the time since the

I was taking that to set the context for the problem paragraph, and your language breaks that connection. I _think_ that's the right thing, but I suggest interested parties look at both paragraphs together.

OTOH, 3 occurrences of the word "immediately" in the same sentence might be a bit much :-) Maybe something like the following:

A notifier is required to send a NOTIFY request immediately after creation of a subscription. If state is not available at that time, then the NOTIFY request may be sent with no content. ... "

---

From: "Thomson, Martin" <[email-masked]>
Date: Sat, 27 Mar 2010 10:06:58 +0800

> OTOH, 3 occurrences of the word "immediately" in the same sentence
> might be a bit much :-) Maybe something like the following:
> 
> A notifier is required to send a NOTIFY request immediately after
> creation of a subscription. If state is not available at that time,
> then the NOTIFY request may be sent with no content. ... "

Quite right.  I'm just tired.  That should have been immediately obvious.