Document: draft-ietf-rserpool-policies-08.txt Reviewer: Elwyn Davies Review Date: 11 April 2008 IETF LC End Date: 14 April 2008 IESG Telechat date: (if known) - Summary: Sorry, guys! This document is not in good shape. I know it is, in a sense, the bottom of the tree and somebody reading it would probably be expected to have read in to the subject through the overview (I scanned it) and the protocol documents (I didn't look at them), but I found the introduction opaque, for example: > > The selection of the pool user is > performed by two different entities. > Which ones? Selection of what? Selection of which pool user to get this week's star prize? Enough of irony and sarcasm: I have two big technical questions about this document (and hence the whole strategy of rserpool): 1. Why do policies appear on the wire in this way? Do the individual servers care about the policy of the group? Would it conceivably work if they weren't all conforming to some preconfigured policy? Is this expected to change over time? Would weights change over time? Seems to me that policy is a preconfigured characteristic of the group. Maybe weight is something that a server might communicate during sign on. Load is dynamic and probably needs to be propagated from time to time. These are all conflated in these protocol elements. Is this good design? Who really needs to know about policies dynamically? 2. Why should pool users have to worry about pool policy? They just want a server. They don't want to have to (and IMO shouldn't have to) try to second guess the pool controllers by munging around it what was allegedly already a prioritized list, surely? In order to do this, especially in the adaptive cases, the pool user needs the weight and load (according to the policy used) for each server passed in the list of servers in response to the request on the rserpool server. It isn't at all clear that this is what happens. Part of the overall problem is that the document does not clearly state which communications use these items, why they would need to and how frequently. There are also detailed issues with the document, but I have to say that I cannot see that we currently have an effective technical design. It is possible that these points have been discussed in the wg; if so some explanation of the motivation for the arrangement is absolutely essential. I am happy to revisit this review if the authors can explain the motivation and suggest text that will get the naive(ish) reader over the understanding hump. Comments: s3.2: > > A weight of 0 denotes that the pool element is not capable of > providing any service, a weight of 2*n denotes that the pool element > is capable of providing a two times better service than a pool > element having weight n. > > For example, weight may define a compute service's computation > capacity. That is, a pool element of weight 100 will complete a work > package in half of the time compared to a pool element of weight 50. > 'two times better'? Any attempt to quantify the meaning of weight beyond a relative ordering of capability will lead to questions such as 'under what conditions?' Leave it to the servers to make what they will of weights - that is the best that the protocol can do. s3 and s4: The encoding of weight and load is not specified other than implicitly. s4.1.3: How does the pool user know some information is out of date? Editorial: s1: Lots of acronyms need expansion. idnits reporst reference issues: Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'Dre2006' is defined on line 615, but no explicit reference was found in the text '[Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, Op...' == Unused Reference: 'LCN2005' is defined on line 623, but no explicit reference was found in the text '[LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of Reli...' == Outdated reference: A later version (-16) exists of draft-ietf-rserpool-common-param-15 == Outdated reference: A later version (-19) exists of draft-ietf-rserpool-asap-18 == Outdated reference: A later version (-19) exists of draft-ietf-rserpool-enrp-18