Draft: draft-zeilenga-ldap-incr-01.txt Reviewer: john.loughney@nokia.com Review Date: Thursday 7/7/2005 2:40 AM CST Telechat Date: 7/7/2005 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.