Document: draft-ietf-rserpool-policies-09.txt
Reviewer: Elwyn Davies
Review Date: 17 June 2008
IESG Telechat date: 19 June 2008

Summary:
The editorial and immediate technical issues with -08 have been fixed.  I remain unconvinced about the appropriateness of the structure of the policy elements as expressed in my last call review.  However since this is now intended for experimental, the value and usefulness of the proposal will be tested in the fire of usage, so I think it can be passed as ready.  I also had some reservations about the lack of explanation as to how the policy elements are used by the protocols.  Communications with the authors suggested that the protocol documents explained this, but a quick scan of the protocol documents did not fully reassure me on this front.  It appears that at least some of the explanation is not in the drafts but in the papers referenced in the drafts. 
Again this is not fatal for experimental status, but would need fixing up for standards.

Comments:

These are the general comments I made at LC together with the authors' responses:

 > 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
Yes, they do. They all use the same policy (with possibly different
paraeters).
 >
 > if they weren't all conforming to some preconfigured policy?  Is this
 > expected to change over time?  Would weights change over time?  Seems to
The parameters may change over time.
 >
 > me that policy is a preconfigured characteristic of the group.  Maybe
Preconfigured would be static.
 >
 > weight is something that a server might communicate during sign on.
 > Load is dynamic and probably needs to be propagated from time to time.
Yes.
 >
 > These are all conflated in these protocol elements.  Is this good
 > design?  Who really needs to know about policies dynamically?
Every node, which does the pool element selection: ENRP server and
Pool user. So it must be communicated.
 >
 >
 > 2. Why should pool users have to worry about pool policy?  They just
Because they can do the pool element selection.
 >
 > 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,
Normally the pool elements do the selection. It is only an option for
the ENRP servers to not give out the complete list.
 >
 > 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.