[ldapext] Re: Gen-Art Review: <draft-zeilenga-ldap-incr-01.txt>

Unfortunately, this review, dated early yesterday, reached me
overnight, after the IESG had approved the draft.

Ted, fyi...

    Brian

john.loughney@nokia.com wrote:
> Background for those on the CC list, who may be unaware of GenART:
> GenART is the Area Review Team for the General Area of the IETF.  We
> advise the General Area Director (i.e. the IETF/IESG chair) by
> providing more in depth reviews than he could do himself of documents
> that come up for final decision in IESG telechat.  I was selected
> as the GenART member to review this document.  Below is my review,
> which was written specifically with an eye to the GenART process, but
> since I believe that it will be useful to have these comments more
> widely distributed, others outside the GenART group are being copied.
> 
> Document: <draft-zeilenga-ldap-incr-01.txt>	
> Intended Status: Informational
> Review Trigger: IETF Telechat, 7/7/2005
> 
> One line summary: This document is not ready for publication as a Informational
> publication.  More text on how to deal with race conditions need to be added.
> 
> General comments:
> 
> 1) Abstact is a little week, after several reads of the abstract, I couldn't
>    make heads or tails what the purpose of the extension is. Could you add
>    an example or purpose, for example:
> 
>   This document describes an extension to the Lightweight Directory
>   Access Protocol (LDAP) Modify operation to support an increment
>   capability, for the purpose of ....
>               ^^^^^^^^^^^^^^^^^^
> 
>   Some some text to put the extension in some perspective would be helpful.
> 
> 2) Security considerations: "aide" should be "aid"
> 
> Major comment:
> 
> 1) I find the text in the first paragraph to be insufficient:
> 
>   ... As the values may be updated by
>   other clients between this add and modify, the client must be careful
>   to construct the modify request so that it fails in this case, and
>   upon failure, re-read the values and construct a new modify request.
> 
>   From my reading, I think what you are saying that clients have to be
>   careful that other clients haven't incremented the values between 
>   the reading of the values and the increment request, but you don't provide
>   any guidence on how this can be done.  My guess is that there could be
>   a number of race situations here.  I am not an LDAP expert so I'm not sure
>   how critical this is.  If it is not a serious issue, then that should be
>   pointed out.  I expect relatively little text is needed to fix this.
> 
> thanks,
> John
>   
> 

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext