From ldapext-bounces@ietf.org Thu Jul 7 04:22:29 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11289 for ; Thu, 7 Jul 2005 04:22:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqS5a-0000LG-KA for ldapext-archive@ietf.org; Thu, 07 Jul 2005 04:50:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRc2-00039Z-3Q; Thu, 07 Jul 2005 04:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRc0-00038i-Jo for ldapext@megatron.ietf.org; Thu, 07 Jul 2005 04:20:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11159 for ; Thu, 7 Jul 2005 04:19:58 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqS37-00088K-Jy for ldapext@ietf.org; Thu, 07 Jul 2005 04:48:04 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j678Jekk016415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2005 08:19:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050707004753.027b35e8@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 01:19:17 -0700 To: From: "Kurt D. Zeilenga" In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia. com> References: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ldapext@ietf.org, gen-art@alvestrand.no Subject: [ldapext] Re: Gen-Art Review: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 John, thanks for your review. Comments below. -- Kurt At 12:39 AM 7/7/2005, 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: >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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jul 7 04:27:05 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11690 for ; Thu, 7 Jul 2005 04:27:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqSA3-00015Z-Ek for ldapext-archive@ietf.org; Thu, 07 Jul 2005 04:55:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRhv-0007nu-0n; Thu, 07 Jul 2005 04:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRht-0007mj-Jo for ldapext@megatron.ietf.org; Thu, 07 Jul 2005 04:26:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11628 for ; Thu, 7 Jul 2005 04:26:03 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqS91-00012D-Tg for ldapext@ietf.org; Thu, 07 Jul 2005 04:54:09 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j678PxDD016962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2005 08:26:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050707012320.06cd4f48@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 01:25:37 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: Gen-Art Review: In-Reply-To: <6.2.1.2.0.20050707004753.027b35e8@mail.openldap.org> References: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia.com> <6.2.1.2.0.20050707004753.027b35e8@mail.openldap.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: gen-art@alvestrand.no, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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, 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: >>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 >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jul 7 09:37:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06834 for ; Thu, 7 Jul 2005 09:37:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX05-0008IB-TP for ldapext-archive@ietf.org; Thu, 07 Jul 2005 10:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWXh-00023A-CV; Thu, 07 Jul 2005 09:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQzG-0004UI-8L for ldapext@megatron.ietf.org; Thu, 07 Jul 2005 03:39:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07884 for ; Thu, 7 Jul 2005 03:39:56 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqRQP-0006xS-1o for ldapext@ietf.org; Thu, 07 Jul 2005 04:08:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j677Z1hH015757; Thu, 7 Jul 2005 10:35:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 10:39:54 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 10:39:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2005 10:39:53 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia.com> Thread-Topic: Gen-Art Review: draft-pullen-srmp-06.txt Thread-Index: AcWCxAmzGZbKJJyeRSmKZ/n7X8y45QAAEqig To: X-OriginalArrivalTime: 07 Jul 2005 07:39:54.0153 (UTC) FILETIME=[10C75990:01C582C7] X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Jul 2005 09:35:52 -0400 Cc: ldapext@ietf.org, Kurt@OpenLDAP.org Subject: [ldapext] Gen-Art Review: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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: =09 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=20 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 =20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jul 7 09:38:30 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06896 for ; Thu, 7 Jul 2005 09:38:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX1Q-0008M5-KS for ldapext-archive@ietf.org; Thu, 07 Jul 2005 10:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWXh-00023h-NB; Thu, 07 Jul 2005 09:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRyz-0006Fz-Gt for ldapext@megatron.ietf.org; Thu, 07 Jul 2005 04:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12686 for ; Thu, 7 Jul 2005 04:43:43 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqSQ8-0004eU-0O for ldapext@ietf.org; Thu, 07 Jul 2005 05:11:49 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 01:43:31 -0700 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 01:43:31 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 01:43:31 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 01:43:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Re: Gen-Art Review: Date: Thu, 7 Jul 2005 01:43:20 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE2460F5AE321@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [ldapext] Re: Gen-Art Review: thread-index: AcWCzZ3Ij/PX3Y3LSvWB+bI2YuJVWgAAgeTQ From: "Paul Leach" To: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 07 Jul 2005 08:43:35.0697 (UTC) FILETIME=[F698B010:01C582CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Jul 2005 09:35:52 -0400 Cc: ldapext@ietf.org, gen-art@alvestrand.no X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable To really motivate it, you need to explain why it won't work to read the old value, add one, and write back the new value. -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On Behalf Of Kurt D. Zeilenga Sent: Thursday, July 07, 2005 1:26 AM To: john.loughney@nokia.com Cc: gen-art@alvestrand.no; ldapext@ietf.org Subject: Re: [ldapext] Re: Gen-Art Review: 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jul 7 19:48:05 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16578 for ; Thu, 7 Jul 2005 19:48:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqgXU-0007pV-KL for ldapext-archive@ietf.org; Thu, 07 Jul 2005 20:16:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqg5E-0007GF-Tm; Thu, 07 Jul 2005 19:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqg5C-0007G6-MI for ldapext@megatron.ietf.org; Thu, 07 Jul 2005 19:47:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16532 for ; Thu, 7 Jul 2005 19:47:02 -0400 (EDT) Received: from eagle.unknowndns.net ([202.60.66.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqgWF-0007nV-Fl for ldapext@ietf.org; Thu, 07 Jul 2005 20:15:17 -0400 Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=[192.168.1.156]) by eagle.unknowndns.net with esmtpa (Exim 4.50) id 1Dqg4c-0004aL-Ts for ldapext@ietf.org; Fri, 08 Jul 2005 09:46:31 +1000 Message-ID: <42CDBED2.1080109@eb2bcom.com> Date: Fri, 08 Jul 2005 09:46:26 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: multipart/mixed; boundary="------------050609070109080702030907" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - eagle.unknowndns.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [ldapext] [Fwd: I-D ACTION:draft-legg-ldap-gser-ei-00.txt] X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 This is a multi-part message in MIME format. --------------050609070109080702030907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, This draft describes a way of annotating an ASN.1 specification to indicate a ChoiceOfStrings type for a GSER encoding. An ASN.1 compiler that is conformant to the latest edition of ASN.1 will at least ignore the annotation if it doesn't understand it. The annotation takes the place of the simple text declaration described in RFC 3641. This draft does not alter the current behaviour of GSER encoders/decoders. I intend recommending this draft to the ISEG as a proposed standard shortly after IETF 63. Regards, Steven -------- Original Message -------- Subject: I-D ACTION:draft-legg-ldap-gser-ei-00.txt Date: Thu, 07 Jul 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Encoding Instructions for the Generic String Encoding Rules (GSER) Author(s) : S. Legg Filename : draft-legg-ldap-gser-ei-00.txt Pages : 9 Date : 2005-7-7 Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER), and in particular defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-ldap-gser-ei-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-legg-ldap-gser-ei-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-legg-ldap-gser-ei-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------050609070109080702030907 Content-Type: Message/External-body; name="draft-legg-ldap-gser-ei-00.txt" Content-Disposition: inline; filename="draft-legg-ldap-gser-ei-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-7-7152613.I-D@ietf.org> --------------050609070109080702030907 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/SLEGG/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/SLEGG/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------050609070109080702030907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --------------050609070109080702030907-- From ldapext-bounces@ietf.org Fri Jul 8 03:43:59 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06750 for ; Fri, 8 Jul 2005 03:43:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqny4-0001bZ-4E for ldapext-archive@ietf.org; Fri, 08 Jul 2005 04:12:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnUX-0002xd-FC; Fri, 08 Jul 2005 03:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnUW-0002xR-31 for ldapext@megatron.ietf.org; Fri, 08 Jul 2005 03:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06542 for ; Fri, 8 Jul 2005 03:41:42 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqnvq-0001TQ-5z for ldapext@ietf.org; Fri, 08 Jul 2005 04:10:00 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j687cRFU002591; Fri, 8 Jul 2005 10:38:28 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 10:41:35 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 10:41:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2005 10:41:34 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CE897@esebe100.NOE.Nokia.com> Thread-Topic: Gen-Art Review: Thread-Index: AcWDj0dekokQ+aQWQ0iTHRd5K+7oPQAASKaQ To: X-OriginalArrivalTime: 08 Jul 2005 07:41:34.0910 (UTC) FILETIME=[773F65E0:01C58390] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: hardie@qualcomm.com, Kurt@OpenLDAP.org, ldapext@ietf.org Subject: [ldapext] RE: Gen-Art Review: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable That's fine by me then. thanks, John > -----Original Message----- > From: ext Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: 08 July, 2005 10:31 > To: Loughney John (Nokia-NRC/Helsinki) > Cc: Ted Hardie; ldapext@ietf.org; Kurt@OpenLDAP.org > Subject: Re: Gen-Art Review: >=20 >=20 > john.loughney@nokia.com wrote: > ... > >=20 > > One line summary: This document is not ready for=20 > publication as a Informational > > publication. More text on how to deal with race conditions=20 > need to be added. >=20 > John, as it happens, I queried Kurt about atomicity and was satisfied = by his > response that LDAP intrinsically provides the required atomicity. That = is kind > of basic in transaction processing, so I don't think it needs spelling = out > in terms of race conditions. >=20 > Brian >=20 >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jul 8 08:40:30 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27607 for ; Fri, 8 Jul 2005 08:40:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqsb2-0003im-9H for ldapext-archive@ietf.org; Fri, 08 Jul 2005 09:08:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqs72-0002y0-DY; Fri, 08 Jul 2005 08:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnG1-0004l2-8t for ldapext@megatron.ietf.org; Fri, 08 Jul 2005 03:26:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05568 for ; Fri, 8 Jul 2005 03:26:44 -0400 (EDT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqnhL-0008H7-0d for ldapext@ietf.org; Fri, 08 Jul 2005 03:55:01 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j687QWe4228620 for ; Fri, 8 Jul 2005 07:26:32 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j687QWRU277172 for ; Fri, 8 Jul 2005 08:26:32 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j687QWr2001688 for ; Fri, 8 Jul 2005 08:26:32 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j687QW5w001670; Fri, 8 Jul 2005 08:26:32 +0100 Received: from zurich.ibm.com (sig-9-145-253-251.de.ibm.com [9.145.253.251]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA50388; Fri, 8 Jul 2005 09:26:21 +0200 Message-ID: <42CE2A89.1080305@zurich.ibm.com> Date: Fri, 08 Jul 2005 09:26:01 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: john.loughney@nokia.com References: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 08 Jul 2005 08:37:47 -0400 Cc: Ted Hardie , Kurt@OpenLDAP.org, ldapext@ietf.org Subject: [ldapext] Re: Gen-Art Review: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit 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: > 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 From ldapext-bounces@ietf.org Fri Jul 8 08:41:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27668 for ; Fri, 8 Jul 2005 08:41:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqsbc-0003kS-Sm for ldapext-archive@ietf.org; Fri, 08 Jul 2005 09:09:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqs72-0002y5-MR; Fri, 08 Jul 2005 08:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnKi-00065U-PK for ldapext@megatron.ietf.org; Fri, 08 Jul 2005 03:31:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05872 for ; Fri, 8 Jul 2005 03:31:35 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqnm2-0000N0-PX for ldapext@ietf.org; Fri, 08 Jul 2005 03:59:52 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j687VOFu154494 for ; Fri, 8 Jul 2005 07:31:24 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j687VOF5124648 for ; Fri, 8 Jul 2005 09:31:24 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j687VOai005785 for ; Fri, 8 Jul 2005 09:31:24 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j687VNbJ005772; Fri, 8 Jul 2005 09:31:23 +0200 Received: from zurich.ibm.com (sig-9-145-253-251.de.ibm.com [9.145.253.251]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA71090; Fri, 8 Jul 2005 09:31:17 +0200 Message-ID: <42CE2BBE.8070009@zurich.ibm.com> Date: Fri, 08 Jul 2005 09:31:10 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: john.loughney@nokia.com References: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CE872@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 08 Jul 2005 08:37:47 -0400 Cc: Ted Hardie , Kurt@OpenLDAP.org, ldapext@ietf.org Subject: [ldapext] Re: Gen-Art Review: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: ... > > 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. John, as it happens, I queried Kurt about atomicity and was satisfied by his response that LDAP intrinsically provides the required atomicity. That is kind of basic in transaction processing, so I don't think it needs spelling out in terms of race conditions. Brian _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jul 20 02:06:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7jB-0005z4-V4; Wed, 20 Jul 2005 02:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7jB-0005uo-1E for ldapext@megatron.ietf.org; Wed, 20 Jul 2005 02:06:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03743 for ; Wed, 20 Jul 2005 02:06:42 -0400 (EDT) Received: from eagle.unknowndns.net ([202.60.66.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv8Cl-0007fy-FY for ldapext@ietf.org; Wed, 20 Jul 2005 02:37:20 -0400 Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=[192.168.1.159]) by eagle.unknowndns.net with esmtpa (Exim 4.50) id 1Dv7ib-0003Ln-Jg; Wed, 20 Jul 2005 16:06:09 +1000 Message-ID: <42DDEB74.1010303@eB2Bcom.com> Date: Wed, 20 Jul 2005 16:13:08 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - eagle.unknowndns.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - eB2Bcom.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Ldapext Subject: [ldapext] Re: I-D ACTION:draft-zeilenga-ldap-dontusecopy-01.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Hi Kurt, > The control is appropriate for both LDAP interrogation operations, > including Compare and Search operations [Protocol]. > > I would probably replace the word 'both' with 'all' and include a little comment about Extended Operations. This way, Extended Operations that perform interrogation operations will also be deemed appropriate to have a dontUseCopy control attached. >When the control is attached to an LDAP request, the requested >operation MUST NOT be performed on copied information. That is, the >requested operation MUST be performed on original information. > > With LDAP directory's that support an implementation of multi-master replication, do you deem both Masters as containing 'original' information? I think that this must be the case, in which case the word 'original' might also be a little misleading. Cheers, Andrew. Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The LDAP Don't Use Copy Control > Author(s) : K. Zeilenga > Filename : draft-zeilenga-ldap-dontusecopy-01.txt > Pages : 5 > Date : 2005-7-19 > >This document defines the Lightweight Directory Access Protocol (LDAP) > Don't Use Copy control extension which allows a client to specify that > copied information should not be used in providing service. This > control is based upon the X.511 dontUseCopy service control option. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-dontusecopy-01.txt > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jul 20 03:48:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv9Je-0006ax-Ni; Wed, 20 Jul 2005 03:48:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv9Jd-0006Yu-3k for ldapext@megatron.ietf.org; Wed, 20 Jul 2005 03:48:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13381 for ; Wed, 20 Jul 2005 03:48:26 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv9nO-0005Db-Ra for ldapext@ietf.org; Wed, 20 Jul 2005 04:19:16 -0400 Received: from gyspy.OpenLDAP.org (slip139-92-202-166.vie.at.prserv.net [139.92.202.166] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j6K7lwxl093974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2005 07:48:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050720033915.031a3428@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Jul 2005 03:47:51 +0200 To: andrew.sciberras@eB2Bcom.com From: "Kurt D. Zeilenga" In-Reply-To: <42DDEB74.1010303@eB2Bcom.com> References: <42DDEB74.1010303@eB2Bcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Ldapext Subject: [ldapext] Re: I-D ACTION:draft-zeilenga-ldap-dontusecopy-01.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 08:13 AM 7/20/2005, Andrew Sciberras wrote: >Hi Kurt, > > >> The control is appropriate for both LDAP interrogation operations, >> including Compare and Search operations [Protocol]. >> >I would probably replace the word 'both' with 'all' and include a little comment about Extended Operations. This way, Extended Operations that perform interrogation operations will also be deemed appropriate to have a dontUseCopy control attached. > > >>When the control is attached to an LDAP request, the requested >>operation MUST NOT be performed on copied information. That is, the >>requested operation MUST be performed on original information. >> >With LDAP directory's that support an implementation of multi-master replication, do you deem both Masters as containing 'original' information? I assume that there must be some agreement between the client and server that allows the server to alter the service model to support multi-master replication (as the X.500(93) service model clearly requires a single master for every object) and that this agreement would be responsible for detailing whether or not both masters are viewed as containing 'original' information. Specification of alternative service models, as well as mechanisms for agreeing to an alternative service model, are well beyond the scope of this document. >I think that this must be the case, in which case the word 'original' might also be a little misleading. See X.500(93). It uses the same terminology when detailing the service control this control is based upon. >Cheers, >Andrew. > > >Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : The LDAP Don't Use Copy Control >> Author(s) : K. Zeilenga >> Filename : draft-zeilenga-ldap-dontusecopy-01.txt >> Pages : 5 >> Date : 2005-7-19 >> >>This document defines the Lightweight Directory Access Protocol (LDAP) >> Don't Use Copy control extension which allows a client to specify that >> copied information should not be used in providing service. This >> control is based upon the X.511 dontUseCopy service control option. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-dontusecopy-01.txt >> _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jul 27 15:31:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrdH-0006q7-0H; Wed, 27 Jul 2005 15:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrdE-0006q2-MU for ldapext@megatron.ietf.org; Wed, 27 Jul 2005 15:31:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26900 for ; Wed, 27 Jul 2005 15:31:54 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxs8X-0000ZG-DJ for ldapext@ietf.org; Wed, 27 Jul 2005 16:04:18 -0400 Received: from gyspy.OpenLDAP.org (slip139-92-202-208.vie.at.prserv.net [139.92.202.208] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j6RJUtI4040815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jul 2005 19:31:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050727103042.0282ea70@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 27 Jul 2005 10:40:41 +0200 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.6 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [ldapext] review of draft-zeilenga-ldap-ext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I intend to submit draft-zeilenga-ldap-ext to the IETF for publication consideration shortly after the Paris IETF. Please review. At present, the I-D says the intended track is Informational. I would much rather have this published as a BCP and am willing to do so if consensus supports such a recommendation. Hence, in your review comments, please note whether or not you believe the guidelines are suitable for publication as a BCP. Thanks, Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext