Hi Hannes, Thanks for the response. Comments inline. I deleted sections that I believe to be resolved. Thanks! Ben. 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@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. 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. > > >> -- 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 >>> 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