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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] 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 > >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? > I don't believe that we introduce modifications to rate-control. >-- 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. > > >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. >-- Section 1, paragraph 1, last sentence: > >I assume their persistence ends when the associated >subscription ends, right? > Correct. I extended the sentence. >-- 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".) > Changed the text according to your suggestion. > >-- 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. > >-- 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. 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. >-- 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. 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. > >-- Section 1, paragraph 2: > >Do you mean to say "[the subscriber] not having to receive...", >or "without the notifier having to issue..."? Fixed. > >-- 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. OK. Fixed. > >-- 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. > Fixed. > Ciao Hannes > >--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 >> >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf