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

["Kurt D. Zeilenga" <[e-mail]>]

Adding to following sentence to the end of the first paragraph
would clarify that the first paragraph is merely providing
background information as to why this extension was developed.

  To avoid the problems of this approach, an extension
  is needed that allows a client to increment attribute values without    
  any requirement for that client to have prior knowledge of the
  attribute values.

comments?

Kurt

At 01:19 AM 7/7/2005, Kurt D. Zeilenga wrote:
>John, thanks for your review.  Comments below.  -- Kurt
>
>At 12:39 AM 7/7/2005, [e-mail] 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.
>
>I think s/increment capability/increment attribute value capability/
>would make it more clear as to what function this extension provides.
>
>>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 ....
>>              ^^^^^^^^^^^^^^^^^^
>
>for the purpose of incrementing attribute values.
>
>I could provide instead an example.
>
>>  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.
>
>As indicated by the first sentence of the paragraph that
>contains this text, this text is providing background information
>regarding what client **not** using this extension must do.
>
>>  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.
>
>The goal of this extension is to avoid the problems due to
>having to issue two (or more) operations where one should do.
>With this extension, a client doesn't not need prior knowledge of
>the attribute value.  (The client can request the value before
>and/or after the increment using pre/post read controls.  These
>controls operate atomically.)
>
>
>
>_______________________________________________
>Ldapext mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ldapext