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

[john.loughney@nokia.com]

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