Re: gen-art review of draft-ietf-rserpool-policies-08.txt

Hi Elwyn,

see my comments in-line.

Best regards
Michael

On Apr 11, 2008, at 2:30 PM, Elwyn Davies wrote:

> 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 resolve these comments along with any other Last Call comments
> you may receive.
>
>
> 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
Yes, it assumes that you have read the ASAP and ENRP documents...
>
> 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?
The sentence is wrong and has been changed to

The selection of the pool element is performed by two different  
entities,
the ENRP server and the pool user.

>
>
> 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
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.
>
> 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.
This is described in the protocol documents. This document describes  
only
the policies, not how the stuff is communicated or used.
>
>
> 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.
I guess the problem is that at least some of the things you are missing
are contained in the protocol documents. this document only focuses on
the policies, the protocols actually work with arbitrary policies.
>
>
> 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.
Clarified that.
>
>
> s3 and s4: The encoding of weight and load is not specified other than
> implicitly.
They are encoded as an 32 uint, network byte order. Text added.
>
>
> s4.1.3: How does the pool user know some information is out of date?
The ASAP document describes that it is possible for a PU to cache
this information. The entries must be flushed after some time. This
is when the information is out of date. When this happens depends on
the application. See the references papers.
>
>
>
> Editorial:
> s1: Lots of acronyms need expansion.
Done.
>
>
> 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...'
Fixed.
>
>
>  == 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...'
Fixed.
>
>
>  == Outdated reference: A later version (-16) exists of
>     draft-ietf-rserpool-common-param-15
Due to sequential submission and usage of xml2rfc.
>
>
>  == Outdated reference: A later version (-19) exists of
>     draft-ietf-rserpool-asap-18
Due to sequential submission and usage of xml2rfc.
>
>
>
>  == Outdated reference: A later version (-19) exists of
>     draft-ietf-rserpool-enrp-18
Due to sequential submission and usage of xml2rfc.

I have submitted a new version which addresses your comments as
described above.
>
>
>
>
>
> _______________________________________________
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf