From owner-ietf-ldup@mail.imc.org Tue Apr 1 04:05:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01564 for ; Tue, 1 Apr 2003 04:05:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h317sYJM015101 for ; Mon, 31 Mar 2003 23:54:34 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h317sYWt015100 for ietf-ldup-bks; Mon, 31 Mar 2003 23:54:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h317sWJM015096 for ; Mon, 31 Mar 2003 23:54:32 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h317sTBT035264; Tue, 1 Apr 2003 07:54:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030331222845.020f1ab0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 31 Mar 2003 23:52:00 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Charter Proposal v2 Cc: In-Reply-To: <00b501c2f7b4$ddd987f0$0300a8c0@D7ST2111> References: <5.2.0.9.0.20030327134718.028bab00@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:39 AM 3/31/2003, Chris Apple wrote: >Comments embedded below. >Chris. > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Thursday, March 27, 2003 5:12 PM >To: capple@dsi-consulting.net >Cc: ietf-ldup@imc.org; John Strassner >Subject: Re: WG Charter Proposal v2 > > >In reading the proposed WG description, I found a discussion >of this WG "was originally chartered" to deliver but I couldn't >any statement as what the WG "is chartered" to delivered, > >CWA> There is language there which treats this topic as implicit. > I have included some additional text below to make the connection > between the original WG direction and the new WG direction more > explicit. This additional text is incorporated into the WG > description as included by you in the posting to which I am > replying now. The added text helps... I'm still a bit confused though. I thought this WG concluded that it wasn't going to reach consensus on LDUP and hence were not going to be able to complete it and, instead, would publish what it had done basically "as is" as experimental/informational with an additional document which detailed the major outstanding issues as indicated in Proposal 1 (in particular 1B). This charter appears to have the WG completing LDUP engineering, albeit producing a complete protocol technical specification. >nor could I find any statement of what work is considered >beyond the scope of the WG. > >CWA> If you have suggestions for how to phrase what work is > out of scope for LDUP in a sentence or two, I'm certainly > open to considering its inclusion. Otherwise, without a > "second" from a few other WG members, I will have to treat > this comment as an isolated one and one that doesn't > represent consensus. Well, for starters: The following activities are beyond the scope of this WG: Revising the LDAP "core" technical specification [RFC3377 and its normative references] (including its information and service models). I would also like to see some statement which states that WG intends avoid achieve a speedy conclusion by documenting areas of contention instead of entering into protracted debate. For example, The WG intends to achieve a speedy conclusion by documenting areas of contention instead of entering into protracted debate. Kurt From owner-ietf-ldup@mail.imc.org Tue Apr 1 11:49:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28667 for ; Tue, 1 Apr 2003 11:49:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GgoJM008142 for ; Tue, 1 Apr 2003 08:42:50 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31GgoXO008141 for ietf-ldup-bks; Tue, 1 Apr 2003 08:42:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31GghJM008130 for ; Tue, 1 Apr 2003 08:42:46 -0800 (PST) Received: from D7ST2111 (pool-141-150-204-116.delv.east.verizon.net [141.150.204.116]) by dns.caledonia.net; Tue, 01 Apr 2003 09:41:26 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: WG Charter Proposal v2 Date: Tue, 1 Apr 2003 11:41:01 -0500 Organization: DSI-Consulting, Inc. Message-ID: <007501c2f86d$8120a840$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030331162717.02117ad0@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31GgnJM008138 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I did make a statement similar to that - it wasn't specifically directed at individual contributions - it was directed at this working group being dependent on deliverables from anywhere outside of the working group to complete its work. Consider the machinations we had to go through to decide how to handle LDAPEXT's failure to produce an ACM standard and the motivation for this comment becomes clear. A similar failure either on the part of another working group or an individual to produce a document that can be published as an RFC represents a similar risk that I as co-chair will seek to avoid if possible. That comment was also not as strong or as broad as you are recalling. I made the comment in response to your suggestion of dissecting certain aspects of LDUP specs out into separate documents. Those types of dissections were what I was referring to when I made this comment. If any such dissections occur, I will require that any such newly created documents become working group documents. As these new documents won't represent new work (we merely chose to create a separate I-D to work on the concept we already were pursuing), a charter revision is not required all that is required is that the I-Ds be published under the LDUP portion of the I-D namespace. This is simply to help minimize the risks associated with having such documents worked on outside of the working group. We already have enough risk to manage. I will not as a co-chair allow additional risk of this type to be added. With regard to *existing* individual contributions that LDUP documents may need to reference, the working group needs to discuss/decide if it wants to add those items to its work program. I note that there are more risks associated with documents who's editors are not accountable to the WG than documents who's editors are accountable to the working group. However, I do not believe it to be appropriate for any co-chair to require that an existing individual I-D become a WG document unless the WG agrees that it should take on the deliverable. I didn't make a statement requiring this to happen. I have strongly argued that it should in the past. I do believe it is appropriate and necessary for me as a co-chair to manage risk associated with existing WG deliverables in the manner that I described above. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, March 31, 2003 7:50 PM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: RE: WG Charter Proposal v2 Chris, at IETF#56, you made some comments regarding problems this group had in the past with referencing individual I-D and how you, as chair, would require that all of the individual I-Ds which this WG depended upon would be brought into the WG and treated as WG I-Ds. Can you clarify what your intended to say at IETF#56 with regard to WG handling of these individual I-Ds? Thanks, Kurt From owner-ietf-ldup@mail.imc.org Tue Apr 1 12:56:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04306 for ; Tue, 1 Apr 2003 12:56:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HmsJM009958 for ; Tue, 1 Apr 2003 09:48:54 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31Hmsuf009957 for ietf-ldup-bks; Tue, 1 Apr 2003 09:48:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31HmqJM009953 for ; Tue, 1 Apr 2003 09:48:53 -0800 (PST) Received: from D7ST2111 (pool-141-150-204-116.delv.east.verizon.net [141.150.204.116]) by dns.caledonia.net; Tue, 01 Apr 2003 10:48:32 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: WG Charter Proposal v2 Date: Tue, 1 Apr 2003 12:48:14 -0500 Organization: DSI-Consulting, Inc. Message-ID: <008601c2f876$e0b25c50$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030331222845.020f1ab0@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comments embedded below. Chris. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, April 01, 2003 2:52 AM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: RE: WG Charter Proposal v2 At 10:39 AM 3/31/2003, Chris Apple wrote: >Comments embedded below. >Chris. > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Thursday, March 27, 2003 5:12 PM >To: capple@dsi-consulting.net >Cc: ietf-ldup@imc.org; John Strassner >Subject: Re: WG Charter Proposal v2 > > >In reading the proposed WG description, I found a discussion >of this WG "was originally chartered" to deliver but I couldn't >any statement as what the WG "is chartered" to delivered, > >CWA> There is language there which treats this topic as implicit. > I have included some additional text below to make the connection > between the original WG direction and the new WG direction more > explicit. This additional text is incorporated into the WG > description as included by you in the posting to which I am > replying now. The added text helps... I'm still a bit confused though. I thought this WG concluded that it wasn't going to reach consensus on LDUP and hence were not going to be able to complete it and, instead, would publish what it had done basically "as is" as experimental/informational with an additional document which detailed the major outstanding issues as indicated in Proposal 1 (in particular 1B). This charter appears to have the WG completing LDUP engineering, albeit producing a complete protocol technical specification. CWA> The WG achieved consensus on Proposal 1. This proposal doesn't state that the WG couldn't reach consensus on LDUP, it acknowledges that there are certain issues on which consensus cannot be established at this time. That is different than stating that we cannot establish any consensus at all - which is what your words imply above. Proposal 1 was one of two proposals for how to conclude LDUP's work given that there are known to be certain issues around which consensus cannot be established at this time. Proposal 1 also was based on the assumption (which was validated by the WG achieving consensus on it) that there is sufficient value to justify a recommendation to the ADs for consideration for publication as largely experimental and informational documents in the work on which we have achieved consensus. LCUP being a notable exception as indicated in Proposal 1. Item 1B of that proposal doesn't state that there should be a separate document identifying outstanding issues. It also doesn't preclude that. The text of 1B implies that outstanding issues should be identified within existing documents. Item 1B also doesn't require that course of action. I left it intentionally fuzzy because I didn't want to restrict the WG from handling it the way it saw fit while doing the work. As long as the intent and work required to address this is reflected somewhere in the WG description (I believe they are), we don't need to decide now if it should be handled within existing documents or in a separate document. >nor could I find any statement of what work is considered >beyond the scope of the WG. > >CWA> If you have suggestions for how to phrase what work is > out of scope for LDUP in a sentence or two, I'm certainly > open to considering its inclusion. Otherwise, without a > "second" from a few other WG members, I will have to treat > this comment as an isolated one and one that doesn't > represent consensus. Well, for starters: The following activities are beyond the scope of this WG: Revising the LDAP "core" technical specification [RFC3377 and its normative references] (including its information and service models). CWA> This is an old discussion based on a perusal of the mailing list archive. However, since views may be different now than in the past. I think its worth waiting for others to weigh in on the issue. If a substantial portion of other WG members state their agreement on the mailing list that the suggested text be included, John and I can consider whether consensus exists on adding it. I would also like to see some statement which states that WG intends avoid achieve a speedy conclusion by documenting areas of contention instead of entering into protracted debate. For example, The WG intends to achieve a speedy conclusion by documenting areas of contention instead of entering into protracted debate. CWA> Same song as above. We need to see agreement posted to the mailing list that it be added. Then John and I will consider consensus on this issue. Kurt From owner-ietf-ldup@mail.imc.org Tue Apr 1 14:37:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09903 for ; Tue, 1 Apr 2003 14:37:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JOpJM014755 for ; Tue, 1 Apr 2003 11:24:51 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JOpxM014754 for ietf-ldup-bks; Tue, 1 Apr 2003 11:24:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JOnJM014750 for ; Tue, 1 Apr 2003 11:24:49 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h31JOlBT040432; Tue, 1 Apr 2003 19:24:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030401094400.021e1218@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Apr 2003 11:22:15 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Charter Proposal v2 Cc: In-Reply-To: <007501c2f86d$8120a840$0300a8c0@D7ST2111> References: <5.2.0.9.0.20030331162717.02117ad0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for the clarification. Comments in line. At 08:41 AM 4/1/2003, Chris Apple wrote: >That comment was also not as strong or as broad as you are recalling. I made >the comment in response to your suggestion of dissecting certain aspects of >LDUP specs out into separate documents. Those types of dissections were what >I was referring to when I made this comment. If any such dissections occur, >I will require that any such newly created documents become working group >documents. Require? >With regard to *existing* individual contributions that LDUP documents may >need >to reference, the working group needs to discuss/decide if it wants to add >those >items to its work program. Yes, the WG needs to discuss/decide this. My opinion: For each "work in progress" the WG believes it needs to have completed for it to complete, it should state what that it will, if necessary, undertake the dependent work. Note here, I do not suggest a general statement, but a set of per I-D specific statements. Something like: The LDUP work requires development of a suitable XXXX feature. Currently the WG intends to reference draft-joe-xxxx being developed on an individual basis. The WG may, if it becomes necessary, undertake the development of the XXXX feature. If and when that becomes necessary, the WG will negotiate appropriate milestones with its AD. From owner-ietf-ldup@mail.imc.org Tue Apr 1 14:39:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10094 for ; Tue, 1 Apr 2003 14:39:15 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JWrJM015094 for ; Tue, 1 Apr 2003 11:32:53 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31JWqWf015093 for ietf-ldup-bks; Tue, 1 Apr 2003 11:32:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31JWpJM015085 for ; Tue, 1 Apr 2003 11:32:51 -0800 (PST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h31JWmn16043 for ; Tue, 1 Apr 2003 11:32:49 -0800 (PST) Received: from netscape.com ([10.169.192.128]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCOJMO01.VL2; Tue, 1 Apr 2003 11:32:48 -0800 Message-ID: <3E89E95F.3050704@netscape.com> Date: Tue, 01 Apr 2003 14:32:47 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: capple@dsi-consulting.net CC: ietf-ldup@imc.org Subject: Re: WG Charter Proposal v2 References: <008601c2f876$e0b25c50$0300a8c0@D7ST2111> In-Reply-To: <008601c2f876$e0b25c50$0300a8c0@D7ST2111> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris Apple wrote: > Well, for starters: > > The following activities are beyond the scope of this WG: > Revising the LDAP "core" technical specification [RFC3377 > and its normative references] (including its information > and service models). > > > CWA> This is an old discussion based on a perusal of the mailing > list archive. However, since views may be different now than > in the past. I think its worth waiting for others to weigh > in on the issue. If a substantial portion of other WG members > state their agreement on the mailing list that the suggested > text be included, John and I can consider whether consensus > exists on adding it. The working group should proceed with caution. If we adopt a statement such as suggested above, an argument could be made that any form of multimaster replication requires an extension of the LDAP models... which means such a charter statement might prevent the WG from progressing some (most?) of the LDUP documents. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Tue Apr 1 17:00:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17363 for ; Tue, 1 Apr 2003 17:00:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LpWJM023477 for ; Tue, 1 Apr 2003 13:51:32 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LpVhv023476 for ietf-ldup-bks; Tue, 1 Apr 2003 13:51:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LpIJM023466 for ; Tue, 1 Apr 2003 13:51:26 -0800 (PST) Received: from D7ST2111 (pool-141-150-204-116.delv.east.verizon.net [141.150.204.116]) by dns.caledonia.net; Tue, 01 Apr 2003 14:50:14 -0700 Reply-To: From: "Chris Apple" To: Cc: "'John Strassner'" Subject: RE: WG Charter Proposal v2 Date: Tue, 1 Apr 2003 16:49:53 -0500 Organization: DSI-Consulting, Inc. Message-ID: <001201c2f898$a3c6afe0$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <001f01c2ef2e$16cfb3c0$5f828182@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31LpVJM023473 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit As a reminder: These issues need to be resolve on the mailing list *before* the April 7th commenting deadline elapses. To-Be-Resolved: Issue 1: Keep multi-master and single-master replication profiles as deliverables? Or remove them. Issue 2: Mandatory (?) Replica Management document title is now somewhat misleading. Perhaps we should change it to *Recommended* Replica Management? John and I are choosing to foster resolution of this issue by changing the way that the issue was raised. If John and I do not see a significant number of postings to the working group mailing list objecting to the document title change, we will declare consensus that we should change the document title, the document editors will make that change with the next revision of the document, and the document title will be changed in the proposed WG charter revision prior to reposting on April 8th. Issue 1 may require a bit of discussion to resolve. Failure to resolve Issue 1 through mailing list discussion by April 7th *could* mean that John and I will be forced to declare that the LDUP WG should not continue its work due to a lack of interest in revising the WG charter. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Thursday, March 20, 2003 5:14 PM To: capple@dsi-consulting.net; ietf-ldup@imc.org Cc: 'John Strassner' Subject: RE: WG Charter Proposal v2 Thanks to Tim Hahn for bringing to my attention that I meant to use April 7, 8, and 15 for the dates below rather than the same days in March. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Thursday, March 20, 2003 6:46 AM To: ietf-ldup@imc.org Cc: John Strassner Subject: WG Charter Proposal v2 Changes in this version: Incorporated comments made during the WG meeting session. Incorporated comments from mailing list. Mostly, these changes related to changing the working group description text to incorporate established consensus on a way to conclude our work. Associated changes to deliverables were also made. To-Be-Resolved: Keep multi-master and single-master replication profiles as deliverables? Or remove them. Mandatory (?) Replica Management document title is now somewhat misleading. Perhaps we should change it to *Recommended* Replica Management? Both of these issues need to be discussed on the mailing list. Any other comments on the WG charter are welcome also. I'm setting deadline for the WG to conclude discussion on revising the charter. Please post all comments to the WG mailing list or send directly to John Strassner and myself no later than: 1700 ET on Monday, March 7, 2003 I will post a final revision reflecting WG consensus to the list on March 8, 2003. After incorporating final comments (to be sure I didn't reflect anything incorrectly), this version will be submitted to the Applications Area Directors for consideration on March 15, 2003. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ----------------------------------------------------------- LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Ned Freed Ted Hardie Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. This group was originally chartered to standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. The WG's approach was to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which were the domain of other working groups. Because the responsible WG failed to achieve consensus on a standard access control model for LDAPv3, the LDUP WG formed a design team to explore the issue of how to address the lack of such a model in the context of LDAPv3 replication. This design team made recommendations to the working group. The working group considered these recommendations and consensus was established on addressing these recommendations in the context of revising other working group deliverables rather than adding new deliverables specific to access control for replication. Largely because of the lack of a standard access control model for LDAPv3, the working group also established consensus on pursuing an experimental or informational publication path for a majority of working group documents formerly intended to become proposed standards. The new replication architecture supports all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o LDAPv3 Profiles Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for: + LDAPv3 Replication General Usage + LDAPv3 Single-Master Directory Replication + LDAPv3 Multi-Master Directory Replication o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The work being done in the LDUP WG should be coordinated to the closest extent possible with similar work being done in the ITU. This is necessary both because LDAP depends on X.500 and because it makes sense from an operational perspective. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit I-D on LDAPv3 Replication Information Model Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Architecture. Done LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Done Submit I-D on LDAPv3 Mandatory Replica Management. Done Submit I-D on LDAPv3 Replication General Usage Profile. Done LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. Done Revise LDAPv3 Client Update Protocol I-D. APR 03 Revise LDAPv3 Replication Information Model I-D. APR 03 Revise LDAPv3 Client Update Protocol I-D. MAY 03 Revise LDAPv3 Update Reconciliation Procedures I-D. MAY 03 Revise LDAPv3 Replication Architecture I-D. MAY 03 Revise LDAPv3 Replication Information Transport Protocol I-D. MAY 03 Revise LDAPv3 Mandatory Replica Management I-D. MAY 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. JUN 03 Revise LDAPv3 Replication General Usage Profile I-D. JUN 03 Submit I-D on LDAPv3 Single-Master Directory Replication Profile. JUN 03 Submit I-D on LDAPv3 Multi-Master Directory Replication Profile. JUN 03 LDAPv3 Replication Information Model I-D goes to WG Last Call as Informational. JUN 03 LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. JUL 03 Revise LDAPv3 Single-Master Directory Replication Profile I-D. JUL 03 Revise LDAPv3 Multi-Master Directory Replication Profile I-D. JUL 03 Revise LDAPv3 Update Reconciliation Procedures I-D. JUL 03 Revise LDAPv3 Replication Information Transport Protocol I-D. JUL 03 Revise LDAPv3 Mandatory Replica Management I-D. JUL 03 Evaluate Deliverables Status AUG 03 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Experimental. SEP 03 LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as Informational. SEP 03 LDAPv3 Single-Master Directory Replication Profile I-D goes to WG Last Call as Informational. SEP 03 LDAPv3 Multi-Master Directory Replication Profile I-D goes to WG Last Call as Informational. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Apr 1 17:03:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17463 for ; Tue, 1 Apr 2003 17:03:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LxLJM023642 for ; Tue, 1 Apr 2003 13:59:21 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31LxLo7023641 for ietf-ldup-bks; Tue, 1 Apr 2003 13:59:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31LxJJM023634 for ; Tue, 1 Apr 2003 13:59:20 -0800 (PST) Received: from D7ST2111 (pool-141-150-204-116.delv.east.verizon.net [141.150.204.116]) by dns.caledonia.net; Tue, 01 Apr 2003 14:59:02 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: WG Charter Proposal v2 Date: Tue, 1 Apr 2003 16:58:43 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000101c2f899$de4f2a10$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <5.2.0.9.0.20030401094400.021e1218@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h31LxLJM023638 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, April 01, 2003 2:22 PM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: RE: WG Charter Proposal v2 Thanks for the clarification. Comments in line. At 08:41 AM 4/1/2003, Chris Apple wrote: >That comment was also not as strong or as broad as you are recalling. I made >the comment in response to your suggestion of dissecting certain aspects of >LDUP specs out into separate documents. Those types of dissections were what >I was referring to when I made this comment. If any such dissections occur, >I will require that any such newly created documents become working group >documents. Require? CWA> This particular topic could prove to be a rat hole while its still all based on the theory of dissecting documents. Lets see where future discussion leads that is about the technical merits of moving specific features out of an existing LDUP document. My point about minimizing risk to completing our work program in short order should be noted. CWA> Requiring that documents primarily focusing on features extracted from an existing LDUP document is a strategy that I will pursue if it actually comes to that. While there would be nothing I could do to stop an individual from publishing such a document outside of the LDUP portion of the I-D namespace, I would hope that folks will keep in mind what's in the best interest of the LDUP WG according to the WG Co-Chairs. Creating new dependencies on new documents external to the WG will create more risk than is called for. CWA> I wanted to respond because you seemed to be unclear about what I could have meant by the word "require" in this context. This particular topic doesn't need to be resolved to revise our charter because it has not been suggested as a topic for inclusion. Lets defer any further discussion on this particular topic until we are actually coping with the reality of dissecting specific features from specific documents. We cannot proceed with that until we are able to move on to revising the documents themselves per the charter revision proposal. >With regard to *existing* individual contributions that LDUP documents may >need >to reference, the working group needs to discuss/decide if it wants to add >those >items to its work program. Yes, the WG needs to discuss/decide this. My opinion: For each "work in progress" the WG believes it needs to have completed for it to complete, it should state what that it will, if necessary, undertake the dependent work. Note here, I do not suggest a general statement, but a set of per I-D specific statements. Something like: The LDUP work requires development of a suitable XXXX feature. Currently the WG intends to reference draft-joe-xxxx being developed on an individual basis. The WG may, if it becomes necessary, undertake the development of the XXXX feature. If and when that becomes necessary, the WG will negotiate appropriate milestones with its AD. CWA> Sounds like a reasonable way to identify external dependencies with one modification - I don't think it's appropriate to reference a specific I-D file name in a WG charter - but some other way of referring to it (a paraphrasing of the document title perhaps). Document editors should post their planned external references to works in progress to the mailing list so we can have the complete set known at this time. These postings should be made before the April 7th end date of the comment window on the charter revision proposal. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Apr 1 18:07:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20008 for ; Tue, 1 Apr 2003 18:07:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31N3wJM027151 for ; Tue, 1 Apr 2003 15:03:58 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31N3wdB027150 for ietf-ldup-bks; Tue, 1 Apr 2003 15:03:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31N3uJM027146 for ; Tue, 1 Apr 2003 15:03:57 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h31N3uBT041638; Tue, 1 Apr 2003 23:03:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030401145756.021d4d30@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Apr 2003 15:01:55 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Charter Proposal v2 Cc: , "'John Strassner'" In-Reply-To: <001201c2f898$a3c6afe0$0300a8c0@D7ST2111> References: <001f01c2ef2e$16cfb3c0$5f828182@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:49 PM 4/1/2003, Chris Apple wrote: >Issue 1: > >Keep multi-master and single-master replication profiles >as deliverables? Or remove them. I suggest removing them. Less work. >Issue 2: > >Mandatory (?) Replica Management document title is >now somewhat misleading. Perhaps we should change it to >*Recommended* Replica Management? I suggest saying "Replica Management"... avoids use of terms which suggest applicability and/or implementation requirement levels. Kurt From owner-ietf-ldup@mail.imc.org Tue Apr 1 21:35:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25952 for ; Tue, 1 Apr 2003 21:35:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322R8JM007372 for ; Tue, 1 Apr 2003 18:27:08 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h322R8bd007371 for ietf-ldup-bks; Tue, 1 Apr 2003 18:27:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h322R6JM007367 for ; Tue, 1 Apr 2003 18:27:06 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h322QwBT042741; Wed, 2 Apr 2003 02:26:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030401175334.01da5f08@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Apr 2003 18:24:54 -0800 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: WG Charter Proposal v2 Cc: capple@dsi-consulting.net, ietf-ldup@imc.org In-Reply-To: <3E89E95F.3050704@netscape.com> References: <008601c2f876$e0b25c50$0300a8c0@D7ST2111> <008601c2f876$e0b25c50$0300a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:32 AM 4/1/2003, Mark C Smith wrote: >Chris Apple wrote: >>Well, for starters: >> The following activities are beyond the scope of this WG: >> Revising the LDAP "core" technical specification [RFC3377 >> and its normative references] (including its information >> and service models). >> >>CWA> This is an old discussion based on a perusal of the mailing >> list archive. However, since views may be different now than >> in the past. I think its worth waiting for others to weigh >> in on the issue. If a substantial portion of other WG members >> state their agreement on the mailing list that the suggested >> text be included, John and I can consider whether consensus >> exists on adding it. > >The working group should proceed with caution. If we adopt a statement such as suggested above, an argument could be made that any form of multimaster replication requires an extension of the LDAP models... which means such a charter statement might prevent the WG from progressing some (most?) of the LDUP documents. Yes, the current documents being produced by the WG assume this WG is chartered to revise the LDAP "core" technical specification (specifically, LDUP changes the LDAP service model) and that's obviously problematic. However, if the WG intents to continue under that assumption that it can revise as necessary the LDAP "core" technical specification, then it should say so in its charter. Or say nothing about this in the charter. That I don't recommend. Kurt From owner-ietf-ldup@mail.imc.org Wed Apr 2 01:12:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00978 for ; Wed, 2 Apr 2003 01:12:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h325xEJM013936 for ; Tue, 1 Apr 2003 21:59:14 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h325xExj013935 for ietf-ldup-bks; Tue, 1 Apr 2003 21:59:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h325x7JM013931 for ; Tue, 1 Apr 2003 21:59:11 -0800 (PST) Received: from D7ST2111 (pool-151-204-199-224.pskn.east.verizon.net [151.204.199.224]) by dns.caledonia.net; Tue, 01 Apr 2003 22:58:43 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: WG Charter Proposal v2 Date: Wed, 2 Apr 2003 00:58:07 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000f01c2f8dc$dbd79ef0$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030401175334.01da5f08@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h325xDJM013932 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Tuesday, April 01, 2003 9:25 PM To: Mark C Smith Cc: capple@dsi-consulting.net; ietf-ldup@imc.org Subject: Re: WG Charter Proposal v2 At 11:32 AM 4/1/2003, Mark C Smith wrote: >Chris Apple wrote: >>Well, for starters: >> The following activities are beyond the scope of this WG: >> Revising the LDAP "core" technical specification [RFC3377 >> and its normative references] (including its information >> and service models). >> >>CWA> This is an old discussion based on a perusal of the mailing >> list archive. However, since views may be different now than >> in the past. I think its worth waiting for others to weigh >> in on the issue. If a substantial portion of other WG members >> state their agreement on the mailing list that the suggested >> text be included, John and I can consider whether consensus >> exists on adding it. > >The working group should proceed with caution. If we adopt a statement such as suggested above, an argument could be made that any form of multimaster replication requires an extension of the LDAP models... which means such a charter statement might prevent the WG from progressing some (most?) of the LDUP documents. Yes, the current documents being produced by the WG assume this WG is chartered to revise the LDAP "core" technical specification (specifically, LDUP changes the LDAP service model) and that's obviously problematic. CWA> Speaking as a Co-Chair, The WG has achieved consensus on pursuing an experimental publication path - the documents (with the exception of LCUP) produced by this WG, if they actually do *require* changes to the LDAP core specifications to be considered implementable, would surely lead to *experimental* updates and not standards track revisions. So from a process point of view this situation, if it actually becomes a reality, is not as problematic as implied above. However, if the WG intents to continue under that assumption that it can revise as necessary the LDAP "core" technical specification, then it should say so in its charter. Or say nothing about this in the charter. That I don't recommend. Kurt CWA> The WG has always intended to handle LDUP specification with LDAPv3 extensibility mechanisms. Initiating any standards track revisions or updates to the core LDAP specifications would be a last resort. So I don't yet buy into your claim that the existing documents assume that LDUP is chartered to revise the core LDAPv3 specifications. Speaking as a WG member, I'll need some justification of that claim to evaluate it. CWA> Please point out to the WG which LDUP features are impossible or impractical to realize without revising the core LDAPv3 specifications, which of those specifications need to be revised, and how those specifications need to be revised for each LDUP feature identified as such. You should also provide a proof or some justification of why each of these features is impossible or impractical to realize using an appropriate combination of LDAPv3 extensibility mechanisms. This is the only way for myself or any other WG member to determine if we agree with your belief that this issue is significant enough to address in the charter revision. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Wed Apr 2 14:01:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23202 for ; Wed, 2 Apr 2003 14:01:01 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IruJM021711 for ; Wed, 2 Apr 2003 10:53:56 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Iru6p021710 for ietf-ldup-bks; Wed, 2 Apr 2003 10:53:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32IrjJM021696 for ; Wed, 2 Apr 2003 10:53:45 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h32IrMBT048171; Wed, 2 Apr 2003 18:53:24 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030402095700.025f26f0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Apr 2003 10:51:18 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Charter Proposal v2 Cc: In-Reply-To: <000f01c2f8dc$dbd79ef0$0300a8c0@D7ST2111> References: <5.2.0.9.0.20030401175334.01da5f08@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:58 PM 4/1/2003, Chris Apple wrote: >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On >Behalf Of Kurt D. Zeilenga >Sent: Tuesday, April 01, 2003 9:25 PM >To: Mark C Smith >Cc: capple@dsi-consulting.net; ietf-ldup@imc.org >Subject: Re: WG Charter Proposal v2 > > > >At 11:32 AM 4/1/2003, Mark C Smith wrote: >>Chris Apple wrote: >>>Well, for starters: >>> The following activities are beyond the scope of this WG: >>> Revising the LDAP "core" technical specification [RFC3377 >>> and its normative references] (including its information >>> and service models). >>> >>>CWA> This is an old discussion based on a perusal of the mailing >>> list archive. However, since views may be different now than >>> in the past. I think its worth waiting for others to weigh >>> in on the issue. If a substantial portion of other WG members >>> state their agreement on the mailing list that the suggested >>> text be included, John and I can consider whether consensus >>> exists on adding it. >> >>The working group should proceed with caution. If we adopt a statement such >as suggested above, an argument could be made that any form of multimaster >replication requires an extension of the LDAP models... which means such a >charter statement might prevent the WG from progressing some (most?) of the >LDUP documents. > >Yes, the current documents being produced by the WG assume >this WG is chartered to revise the LDAP "core" technical >specification (specifically, LDUP changes the LDAP >service model) and that's obviously problematic. > >CWA> Speaking as a Co-Chair, The WG has achieved consensus > on pursuing an experimental publication path - the documents > (with the exception of LCUP) produced by this WG, if they > actually do *require* changes to the LDAP core specifications > to be considered implementable, would surely lead to *experimental* > updates and not standards track revisions. So from a process > point of view this situation, if it actually becomes a > reality, is not as problematic as implied above. I think an experimental LDUP would be even more problematic as it update the service model in a way which would break non-LDUP-aware clients which excepted standard-track behavior from the LDUP-aware LDAP servers they peer with. >However, if the WG intents to continue under that assumption >that it can revise as necessary the LDAP "core" technical >specification, then it should say so in its charter. > >Or say nothing about this in the charter. That I don't recommend. > >Kurt > >CWA> The WG has always intended to handle LDUP specification with > LDAPv3 extensibility mechanisms. The issue is not what mechanisms is used, but whether or not LDUP specifications revise the LDAP information and service models in a manner which breaks non-LDUP-aware LDAP implementations. >Initiating any standards > track revisions or updates to the core LDAP specifications > would be a last resort. So I don't yet buy into your claim > that the existing documents assume that LDUP is chartered > to revise the core LDAPv3 specifications. Speaking as a WG > member, I'll need some justification of that claim to evaluate > it. I suggest you review the archives of past discussions in this area. Here's one URL on the topic (at the head of this thread you will find an example of a conformant (and common) LDAP use scenario which LDUP will break.) http://www.imc.org/ietf-ldup/mail-archive/msg00672.html As folks seem not to get the impact MM will have on current conformant LDAP deployments, I will prepare an I-D on the subject. My working title is "Multi-master replication considered harmful to LDAP/X.500 directory services". >CWA> Please point out to the WG which LDUP features are impossible > or impractical to realize without revising the core LDAPv3 > specifications, Multi-master replication without tight data consistency between the client issuing the modification and the set of master replicas. >which of those specifications need to > be revised, I suspect most would have to be changed. >and how those specifications need to be revised > for each LDUP feature identified as such. Basically, they have to ensure that if a modify succeed iff the update was made to all masters and if a modify failed, no update to any master is made. That is, the service provided to a client in the same regardless of whether there is one master or many. Alternatively, eliminate multi-master support. >You should also > provide a proof or some justification of why each of these > features is impossible or impractical to realize using an > appropriate combination of LDAPv3 extensibility mechanisms. As I said above, I will write an I-D will details how the introduction of loss-consistency multi-master replication will break directory applications. > This is the only way for myself or any other WG member to > determine if we agree with your belief that this issue is > significant enough to address in the charter revision. Unfornately, I doubt I'll be able to produce an I-D before the charter revision cutoff. However, I would hope most LDUP'ers understand the LDAP service model issue. It's been discussed repeatedly on this list. Kurt From owner-ietf-ldup@mail.imc.org Wed Apr 2 14:46:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25116 for ; Wed, 2 Apr 2003 14:46:15 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JXIJM024599 for ; Wed, 2 Apr 2003 11:33:18 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32JXIEV024598 for ietf-ldup-bks; Wed, 2 Apr 2003 11:33:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32JX4JM024587 for ; Wed, 2 Apr 2003 11:33:11 -0800 (PST) Received: from D7ST2111 (pool-141-150-207-119.delv.east.verizon.net [141.150.207.119]) by dns.caledonia.net; Wed, 02 Apr 2003 12:32:08 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: WG Charter Proposal v2 Date: Wed, 2 Apr 2003 14:31:43 -0500 Organization: DSI-Consulting, Inc. Message-ID: <000c01c2f94e$87859880$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.2.0.9.0.20030402095700.025f26f0@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h32JXIJM024595 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, April 02, 2003 1:51 PM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: RE: WG Charter Proposal v2 At 09:58 PM 4/1/2003, Chris Apple wrote: >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On >Behalf Of Kurt D. Zeilenga >Sent: Tuesday, April 01, 2003 9:25 PM >To: Mark C Smith >Cc: capple@dsi-consulting.net; ietf-ldup@imc.org >Subject: Re: WG Charter Proposal v2 > > > >At 11:32 AM 4/1/2003, Mark C Smith wrote: >>Chris Apple wrote: >>>Well, for starters: >>> The following activities are beyond the scope of this WG: >>> Revising the LDAP "core" technical specification [RFC3377 >>> and its normative references] (including its information >>> and service models). >>> >>>CWA> This is an old discussion based on a perusal of the mailing >>> list archive. However, since views may be different now than >>> in the past. I think its worth waiting for others to weigh >>> in on the issue. If a substantial portion of other WG members >>> state their agreement on the mailing list that the suggested >>> text be included, John and I can consider whether consensus >>> exists on adding it. >> >>The working group should proceed with caution. If we adopt a statement such >as suggested above, an argument could be made that any form of multimaster >replication requires an extension of the LDAP models... which means such a >charter statement might prevent the WG from progressing some (most?) of the >LDUP documents. > >Yes, the current documents being produced by the WG assume >this WG is chartered to revise the LDAP "core" technical >specification (specifically, LDUP changes the LDAP >service model) and that's obviously problematic. > >CWA> Speaking as a Co-Chair, The WG has achieved consensus > on pursuing an experimental publication path - the documents > (with the exception of LCUP) produced by this WG, if they > actually do *require* changes to the LDAP core specifications > to be considered implementable, would surely lead to *experimental* > updates and not standards track revisions. So from a process > point of view this situation, if it actually becomes a > reality, is not as problematic as implied above. I think an experimental LDUP would be even more problematic as it update the service model in a way which would break non-LDUP-aware clients which excepted standard-track behavior from the LDUP-aware LDAP servers they peer with. CWA> I think you may be missing the point of the experimental publication path. Part of the point that you make above will have to be noted as a known issue in the documents that LDUP will seek to progress. You may not agree with the working group consensus that such a path is useful and indeed you seem to be advocating that an experimental LDUP is even harmful if used in the context of multi-master replication. There isn't anything wrong per se with your holding that viewpoint, but I need to remind you as a co-chair that this particular comment/thread is not in line with an already established WG consensus on how we will proceed. >However, if the WG intents to continue under that assumption >that it can revise as necessary the LDAP "core" technical >specification, then it should say so in its charter. > >Or say nothing about this in the charter. That I don't recommend. > >Kurt > >CWA> The WG has always intended to handle LDUP specification with > LDAPv3 extensibility mechanisms. The issue is not what mechanisms is used, but whether or not LDUP specifications revise the LDAP information and service models in a manner which breaks non-LDUP-aware LDAP implementations. >Initiating any standards > track revisions or updates to the core LDAP specifications > would be a last resort. So I don't yet buy into your claim > that the existing documents assume that LDUP is chartered > to revise the core LDAPv3 specifications. Speaking as a WG > member, I'll need some justification of that claim to evaluate > it. I suggest you review the archives of past discussions in this area. Here's one URL on the topic (at the head of this thread you will find an example of a conformant (and common) LDAP use scenario which LDUP will break.) http://www.imc.org/ietf-ldup/mail-archive/msg00672.html CWA> Already did. As folks seem not to get the impact MM will have on current conformant LDAP deployments, I will prepare an I-D on the subject. My working title is "Multi-master replication considered harmful to LDAP/X.500 directory services". CWA> Again, it is WG consensus to note such issues as known and move on with experimental publication. >CWA> Please point out to the WG which LDUP features are impossible > or impractical to realize without revising the core LDAPv3 > specifications, Multi-master replication without tight data consistency between the client issuing the modification and the set of master replicas. CWA> Point noted - it will have to be described with appropriate caveats in the experimental documents that are published. >which of those specifications need to > be revised, I suspect most would have to be changed. CWA> Without a specific analysis its not possible for anyone to fully understand the magnitude or impact of such updates/revisions/etc. on experimental/pilot implementations and deployments and how those are likely to interact (or not) with standards-based implementations. Again, that's behind part of the motivation for pursuing experimental rather than standards track publication. >and how those specifications need to be revised > for each LDUP feature identified as such. Basically, they have to ensure that if a modify succeed iff the update was made to all masters and if a modify failed, no update to any master is made. That is, the service provided to a client in the same regardless of whether there is one master or many. Alternatively, eliminate multi-master support. CWA> Which is one thing that LDUP document editors need to be aware of as they revise their documents one final time. Some documents will need to have statements included that identify this as an uncertain/unknown/underspecified area. >You should also > provide a proof or some justification of why each of these > features is impossible or impractical to realize using an > appropriate combination of LDAPv3 extensibility mechanisms. As I said above, I will write an I-D will details how the introduction of loss-consistency multi-master replication will break directory applications. > This is the only way for myself or any other WG member to > determine if we agree with your belief that this issue is > significant enough to address in the charter revision. Unfornately, I doubt I'll be able to produce an I-D before the charter revision cutoff. However, I would hope most LDUP'ers understand the LDAP service model issue. It's been discussed repeatedly on this list. Kurt CWA> I'm sure they do understand this issue. Also, I think that Mark Smith used a word in his original reply to this portion of the thread. The implication that it may be possible to to address the complexity of multi-master replication with an extension to rather than a revision of the core service model. Perhaps Mark can elaborate a bit to clarify his intended meaning? Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Wed Apr 2 15:21:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07506 for ; Wed, 2 Apr 2003 15:21:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32K6jJM025732 for ; Wed, 2 Apr 2003 12:06:45 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32K6jdP025731 for ietf-ldup-bks; Wed, 2 Apr 2003 12:06:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32K6iJM025727 for ; Wed, 2 Apr 2003 12:06:44 -0800 (PST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h32K6Rks011843; Wed, 2 Apr 2003 12:06:28 -0800 (PST) Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h32K6Pcr014301; Wed, 2 Apr 2003 12:06:26 -0800 (PST) Date: Wed, 2 Apr 2003 12:06:26 -0800 Subject: Re: WG Charter Proposal v2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , To: "Kurt D. Zeilenga" From: Ted Hardie In-Reply-To: <5.2.0.9.0.20030402095700.025f26f0@127.0.0.1> Message-Id: <95A6260E-6546-11D7-83A5-000393CB0816@qualcomm.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Kurt, While I understand that LDUP is currently going through a re-charter exercise, I believe that this re-charter should be grounded in the existing charter. Multi-master replication is clearly a major task given to LDUP in the existing charter--it is "bullet one" so to speak. It seems clear to me that its presence in the original charter reflects a view of the IETF community that replication would be a valuable addition to the future of the LDAP service constellation. Requiring that the working group take appropriate care not to make capricious changes to the core service to which it applies is appropriate, and I believe the Chairs have been clear that it is their intent to take due care on this point. I assume that you and other working group members will also be following the work carefully, and that issues which require broad community review can be coordinated among the interested parties. That coordination should not imply prior restraint, if you will pardon the borrowing from a different area. There is a fine line between requiring that due care be taken and requiring that the working group limit its efforts in ways that may mean that it cannot produce its deliverables. From my perspective, LDUP has already been chartered to produce the best replication system it can; after producing it, the WG can exercise its best judgment as to whether that product is ready for the standards track or should be documented as experimental. That judgment should obviously be informed by coordination with other groups as and after the replication service is developed. I am happy that you will be writing a draft to document your concerns. As you do so, I would personally find it valuable if you documented what changes to the service model you believe might be required to bring the LDAP service model and replication together. Obviously, no one one wants to make needless changes, but we do need to be open to extension in order to ensure that the suite of LDAP services are as complete as possible as we move forward. Thanks again, best regards, Ted Hardie On Wednesday, April 2, 2003, at 10:51 AM, Kurt D. Zeilenga wrote: > > At 09:58 PM 4/1/2003, Chris Apple wrote: > >> -----Original Message----- >> From: owner-ietf-ldup@mail.imc.org >> [mailto:owner-ietf-ldup@mail.imc.org] On >> Behalf Of Kurt D. Zeilenga >> Sent: Tuesday, April 01, 2003 9:25 PM >> To: Mark C Smith >> Cc: capple@dsi-consulting.net; ietf-ldup@imc.org >> Subject: Re: WG Charter Proposal v2 >> >> >> >> At 11:32 AM 4/1/2003, Mark C Smith wrote: >>> Chris Apple wrote: >>>> Well, for starters: >>>> The following activities are beyond the scope of this WG: >>>> Revising the LDAP "core" technical specification [RFC3377 >>>> and its normative references] (including its information >>>> and service models). >>>> >>>> CWA> This is an old discussion based on a perusal of the mailing >>>> list archive. However, since views may be different now than >>>> in the past. I think its worth waiting for others to weigh >>>> in on the issue. If a substantial portion of other WG members >>>> state their agreement on the mailing list that the suggested >>>> text be included, John and I can consider whether consensus >>>> exists on adding it. >>> >>> The working group should proceed with caution. If we adopt a >>> statement such >> as suggested above, an argument could be made that any form of >> multimaster >> replication requires an extension of the LDAP models... which means >> such a >> charter statement might prevent the WG from progressing some (most?) >> of the >> LDUP documents. >> >> Yes, the current documents being produced by the WG assume >> this WG is chartered to revise the LDAP "core" technical >> specification (specifically, LDUP changes the LDAP >> service model) and that's obviously problematic. >> >> CWA> Speaking as a Co-Chair, The WG has achieved consensus >> on pursuing an experimental publication path - the documents >> (with the exception of LCUP) produced by this WG, if they >> actually do *require* changes to the LDAP core specifications >> to be considered implementable, would surely lead to >> *experimental* >> updates and not standards track revisions. So from a process >> point of view this situation, if it actually becomes a >> reality, is not as problematic as implied above. > > I think an experimental LDUP would be even more problematic > as it update the service model in a way which would break > non-LDUP-aware clients which excepted standard-track behavior > from the LDUP-aware LDAP servers they peer with. > >> However, if the WG intents to continue under that assumption >> that it can revise as necessary the LDAP "core" technical >> specification, then it should say so in its charter. >> >> Or say nothing about this in the charter. That I don't recommend. >> >> Kurt >> >> CWA> The WG has always intended to handle LDUP specification with >> LDAPv3 extensibility mechanisms. > > The issue is not what mechanisms is used, but whether or > not LDUP specifications revise the LDAP information and service > models in a manner which breaks non-LDUP-aware LDAP implementations. > >> Initiating any standards >> track revisions or updates to the core LDAP specifications >> would be a last resort. So I don't yet buy into your claim >> that the existing documents assume that LDUP is chartered >> to revise the core LDAPv3 specifications. Speaking as a WG >> member, I'll need some justification of that claim to evaluate >> it. > > I suggest you review the archives of past discussions in this > area. Here's one URL on the topic (at the head of this thread > you will find an example of a conformant (and common) LDAP use > scenario which LDUP will break.) > http://www.imc.org/ietf-ldup/mail-archive/msg00672.html > > As folks seem not to get the impact MM will have on current > conformant LDAP deployments, I will prepare an I-D on the > subject. My working title is "Multi-master replication > considered harmful to LDAP/X.500 directory services". > >> CWA> Please point out to the WG which LDUP features are impossible >> or impractical to realize without revising the core LDAPv3 >> specifications, > > Multi-master replication without tight data consistency between > the client issuing the modification and the set of master replicas. > >> which of those specifications need to >> be revised, > > I suspect most would have to be changed. > >> and how those specifications need to be revised >> for each LDUP feature identified as such. > > Basically, they have to ensure that if a modify succeed iff > the update was made to all masters and if a modify failed, > no update to any master is made. That is, the service > provided to a client in the same regardless of whether there > is one master or many. > > Alternatively, eliminate multi-master support. > >> You should also >> provide a proof or some justification of why each of these >> features is impossible or impractical to realize using an >> appropriate combination of LDAPv3 extensibility mechanisms. > > As I said above, I will write an I-D will details how the > introduction of loss-consistency multi-master replication > will break directory applications. > >> This is the only way for myself or any other WG member to >> determine if we agree with your belief that this issue is >> significant enough to address in the charter revision. > > Unfornately, I doubt I'll be able to produce an I-D before the > charter revision cutoff. However, I would hope most LDUP'ers > understand the LDAP service model issue. It's been discussed > repeatedly on this list. > > Kurt > > From owner-ietf-ldup@mail.imc.org Wed Apr 2 16:06:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09218 for ; Wed, 2 Apr 2003 16:06:12 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KukJM001638 for ; Wed, 2 Apr 2003 12:56:46 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32KukuW001637 for ietf-ldup-bks; Wed, 2 Apr 2003 12:56:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KujJM001607 for ; Wed, 2 Apr 2003 12:56:45 -0800 (PST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h32Kugn23311 for ; Wed, 2 Apr 2003 12:56:42 -0800 (PST) Received: from netscape.com ([10.169.192.48]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCQI6I02.UU3; Wed, 2 Apr 2003 12:56:42 -0800 Message-ID: <3E8B4E89.1090206@netscape.com> Date: Wed, 02 Apr 2003 15:56:41 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: capple@dsi-consulting.net CC: ietf-ldup@imc.org Subject: Re: WG Charter Proposal v2 References: <000c01c2f94e$87859880$0300a8c0@D7ST2111> In-Reply-To: <000c01c2f94e$87859880$0300a8c0@D7ST2111> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris Apple wrote: > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > ... > Unfornately, I doubt I'll be able to produce an I-D before the > charter revision cutoff. However, I would hope most LDUP'ers > understand the LDAP service model issue. It's been discussed > repeatedly on this list. > > Kurt > > CWA> I'm sure they do understand this issue. Also, I think that > Mark Smith used a word in his original reply to this portion > of the thread. The implication that it may be possible to > to address the complexity of multi-master replication > with an extension to rather than a revision of the core > service model. Perhaps Mark can elaborate a bit to clarify > his intended meaning? I do not remember using any magic word. But in my opinion it is sufficient for the LDUP documents to specify what impact deployment of LDUP replication might have on LDAP clients and to specify how clients can, if neccessary, discover that LDUP replication is in use. -Mark From owner-ietf-ldup@mail.imc.org Wed Apr 2 16:15:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09560 for ; Wed, 2 Apr 2003 16:15:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KxbJM002066 for ; Wed, 2 Apr 2003 12:59:37 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h32Kxbg7002065 for ietf-ldup-bks; Wed, 2 Apr 2003 12:59:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h32KxWJM002053 for ; Wed, 2 Apr 2003 12:59:34 -0800 (PST) Received: from D7ST2111 (pool-141-150-207-119.delv.east.verizon.net [141.150.207.119]) by dns.caledonia.net; Wed, 02 Apr 2003 13:58:53 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: WG Charter Proposal v2 Date: Wed, 2 Apr 2003 15:58:40 -0500 Organization: DSI-Consulting, Inc. Message-ID: <001901c2f95a$a4bd7dd0$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >You should also > provide a proof or some justification of why each of these > features is impossible or impractical to realize using an > appropriate combination of LDAPv3 extensibility mechanisms. As I said above, I will write an I-D will details how the introduction of loss-consistency multi-master replication will break directory applications. > This is the only way for myself or any other WG member to > determine if we agree with your belief that this issue is > significant enough to address in the charter revision. Unfornately, I doubt I'll be able to produce an I-D before the charter revision cutoff. However, I would hope most LDUP'ers understand the LDAP service model issue. It's been discussed repeatedly on this list. Kurt CWA> I also intended to say that I am glad you have agreed to produce such a draft. I'm sure it will be useful input for the LDUP editors to consider as they produce the final revisions of their I-Ds. So even if this I-D is published after April 7th, it is useful. Sometime early in the month of May would be ideal. Please post an announcement of it being available to the LDUP mailing list. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Wed Apr 2 20:33:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20386 for ; Wed, 2 Apr 2003 20:33:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h331MPJM016728 for ; Wed, 2 Apr 2003 17:22:25 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h331MPx1016726 for ietf-ldup-bks; Wed, 2 Apr 2003 17:22:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h331MNJM016722 for ; Wed, 2 Apr 2003 17:22:23 -0800 (PST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h331MFBT051394; Thu, 3 Apr 2003 01:22:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030402165922.02704e28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 02 Apr 2003 17:20:12 -0800 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: WG Charter Proposal v2 Cc: capple@dsi-consulting.net, ietf-ldup@imc.org In-Reply-To: <3E8B4E89.1090206@netscape.com> References: <000c01c2f94e$87859880$0300a8c0@D7ST2111> <000c01c2f94e$87859880$0300a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:56 PM 4/2/2003, Mark C Smith wrote: >I do not remember using any magic word. But in my opinion it is sufficient for the LDUP documents to specify what impact deployment of LDUP replication might have on LDAP clients and to specify how clients can, if neccessary, discover that LDUP replication is in use. With LDUP replication documents being published on the Experimental track, this likely can be handled by clear, concise, and prominent note providing appropriate warnings, disclaimers, restrictions, applicability statements, and such. This note should also be supplement with more detailed discussion of the issues, possibly referencing the I-D I intend to write. I would be willing to discuss (at a later date, ~June) this I-D becoming one of the supplementary informational WG I-Ds discussed in the proposed charter. Kurt From owner-ietf-ldup@mail.imc.org Thu Apr 3 02:47:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09465 for ; Thu, 3 Apr 2003 02:47:15 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h337ccJM005382 for ; Wed, 2 Apr 2003 23:38:38 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h337ccAV005381 for ietf-ldup-bks; Wed, 2 Apr 2003 23:38:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h337cVJM005335 for ; Wed, 2 Apr 2003 23:38:34 -0800 (PST) Received: from D7ST2111 (pool-141-150-207-119.delv.east.verizon.net [141.150.207.119]) by dns.caledonia.net; Thu, 03 Apr 2003 00:37:57 -0700 Reply-To: From: "Chris Apple" To: Subject: RE: WG Charter Proposal v2 Date: Thu, 3 Apr 2003 02:37:41 -0500 Organization: DSI-Consulting, Inc. Message-ID: <001401c2f9b3$ee0914f0$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E8B4E89.1090206@netscape.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark, Sorry for being obtuse. You used the word extension in relation to the LDAP models. "...an argument could be made that any form of multimaster replication requires an extension of the LDAP models..." I was looking for some clarification about what you could have meant by extension in this context. The suggestion below seems quite reasonable for editors to consider during their final revisions of LDUP documents. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Mark C Smith Sent: Wednesday, April 02, 2003 3:57 PM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: Re: WG Charter Proposal v2 Chris Apple wrote: > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > ... > Unfornately, I doubt I'll be able to produce an I-D before the > charter revision cutoff. However, I would hope most LDUP'ers > understand the LDAP service model issue. It's been discussed > repeatedly on this list. > > Kurt > > CWA> I'm sure they do understand this issue. Also, I think that > Mark Smith used a word in his original reply to this portion > of the thread. The implication that it may be possible to > to address the complexity of multi-master replication > with an extension to rather than a revision of the core > service model. Perhaps Mark can elaborate a bit to clarify > his intended meaning? I do not remember using any magic word. But in my opinion it is sufficient for the LDUP documents to specify what impact deployment of LDUP replication might have on LDAP clients and to specify how clients can, if neccessary, discover that LDUP replication is in use. -Mark From owner-ietf-ldup@mail.imc.org Thu Apr 3 09:26:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20910 for ; Thu, 3 Apr 2003 09:26:19 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33EHUJM016885 for ; Thu, 3 Apr 2003 06:17:30 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h33EHUcT016884 for ietf-ldup-bks; Thu, 3 Apr 2003 06:17:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from netscape.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h33EHTJM016876 for ; Thu, 3 Apr 2003 06:17:29 -0800 (PST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h33EHPn17565 for ; Thu, 3 Apr 2003 06:17:25 -0800 (PST) Received: from netscape.com ([10.169.192.46]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HCRUCS02.516; Thu, 3 Apr 2003 06:17:16 -0800 Message-ID: <3E8C4274.3090406@netscape.com> Date: Thu, 03 Apr 2003 09:17:24 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: capple@dsi-consulting.net CC: ietf-ldup@imc.org Subject: Re: WG Charter Proposal v2 References: <001401c2f9b3$ee0914f0$0300a8c0@D7ST2111> In-Reply-To: <001401c2f9b3$ee0914f0$0300a8c0@D7ST2111> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris Apple wrote: > Mark, > > Sorry for being obtuse. You used the word extension in > relation to the LDAP models. > > "...an argument could be made that any form of > multimaster replication requires an extension of > the LDAP models..." > > I was looking for some clarification about what you > could have meant by extension in this context. > > The suggestion below seems quite reasonable for editors to > consider during their final revisions of LDUP documents. I meant "extension" in the most general sense of the word. I think Kurt's point is that if multimaster replication (MMR) is deployed, there are certain things that LDAP clients can no longer assume to be true. For example, a client can no longer assume that only one writeable copy of an entry exists. Because that knowledge may be really important to a client, LDUP should perhaps provide a way for clients to discover that MMR is in use. But I don't think most proprietary MMR implementations both providing such a discovery mechanism so one could argue this is not a big problem in practice. Certainly it seems to me that experimental RFCs are just that: experimental. If problems are discovered by the brave implementers and deployers who adopt such as RFC, then the specifications can be revised or we can all conclude that the experiment was a failure. No one HAS to use any of this stuff. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From subs-reminder@imc.org Mon Apr 7 14:41:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00391 for ; Mon, 7 Apr 2003 14:41:41 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37IiBJM004597 for ; Mon, 7 Apr 2003 11:44:11 -0700 (PDT) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37IiBkF004596; Mon, 7 Apr 2003 11:44:11 -0700 (PDT) Date: Mon, 7 Apr 2003 11:44:11 -0700 (PDT) Message-Id: <200304071844.h37IiBkF004596@above.proper.com> To: ldup-archive@ietf.org Subject: [[479304719]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From subs-reminder@imc.org Mon Apr 7 14:43:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00430 for ; Mon, 7 Apr 2003 14:43:07 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37IjbJM004890 for ; Mon, 7 Apr 2003 11:45:37 -0700 (PDT) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37IjabS004889; Mon, 7 Apr 2003 11:45:36 -0700 (PDT) Date: Mon, 7 Apr 2003 11:45:36 -0700 (PDT) Message-Id: <200304071845.h37IjabS004889@above.proper.com> To: ldup-archive@ietf.org Subject: [[397576722]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ldup@mail.imc.org Wed Apr 9 00:43:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18377 for ; Wed, 9 Apr 2003 00:43:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h394VoJM005927 for ; Tue, 8 Apr 2003 21:31:50 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h394VoDx005926 for ietf-ldup-bks; Tue, 8 Apr 2003 21:31:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h394VmJM005922 for ; Tue, 8 Apr 2003 21:31:49 -0700 (PDT) Received: from D7ST2111 (pool-151-204-72-249.delv.east.verizon.net [151.204.72.249]) by dns.caledonia.net; Tue, 08 Apr 2003 22:30:36 -0600 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: WG Charter Revision - Consensus Version Date: Wed, 9 Apr 2003 00:31:02 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000f01c2fe50$d5571cd0$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have incorporated all comments on which consensus could be determined. Largely, this means that if there was no affirmative discussion related to a particular comment initiated by someone other than the person creating the original posting containing the comment, that comment was deemed not to represent the consensus of the WG and was thus not reflected as a change in the WG charter. The period for introducing new comments related to changing the working group description or presence (and wording) of deliverables is now closed. John and I will now accept comments of the following types: - typos and grammatical errors - administrative input such as "that date should be changed to this other date because of the following reason" - corrections or word choice to the changes reflected in the WG charter description or the deliverables list that appear to be in error as they were translated from mailing list discussion into this charter revision - any other administrative changes that do not involve a material change in the intent of the WG to pursue the path towards concluding our work on which we established prior consensus Because I am posting this message around 12:30 AM, US ET on April 9, 2003 instead of the originally intended April 8, 2003, I am shifting the administrative review period and subsequent submittal to the Applications Area Directors by one calendar day. This primarily administrative comment period will remain open until 1700 ET, April 15, 2003. Please post any comments of the types described above on or before that time. On April 16, 2003, John and I will send a copy of the final revised charter to the Applications Area Directors for consideration for recommendation to the IESG for Approval. I will acknowledge an intent to (or not to) incorporate each comment posted during the administrative review period and will Cc: the LDUP WG mailing list when submitting the final version to the ADs. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ---------------------------------------------------------------- LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Ned Freed Ted Hardie Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. This group was originally chartered to standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Recently, the WG established consensus on a change of direction to pursue publication of a standards track protocol for LDAPv3 client synchronization, an experimental LDAPv3 replication protocol, and supporting informational documents. Thus the new work program is largely the same as the original work program with one notable exception, the LDAPv3 replication protocol is intended to be an experimental rather than a standards track protocol. The WG's approach was to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which were the domain of other working groups. Because the responsible WG failed to achieve consensus on a standard access control model for LDAPv3, the LDUP WG formed a design team to explore the issue of how to address the lack of such a model in the context of LDAPv3 replication. This design team made recommendations to the working group. The working group considered these recommendations and consensus was established on addressing these recommendations in the context of revising other working group deliverables rather than adding new deliverables specific to access control for replication. Largely because of the lack of a standard access control model for LDAPv3, the working group also established consensus on pursuing an experimental or informational publication path for a majority of working group documents formerly intended to become proposed standards. The new replication architecture supports all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Replica Management Specifications designed to support administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o A General Usage Profile of the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures. o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The work being done in the LDUP WG should be coordinated to the closest extent possible with similar work being done in the ITU. This is necessary both because LDAP depends on X.500 and because it makes sense from an operational perspective. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Architecture. Done LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Done Submit I-D on LDAPv3 Mandatory Replica Management. Done Submit I-D on LDAPv3 Replication General Usage Profile. Done LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. Done Revise LDAPv3 Client Update Protocol I-D. APR 03 Revise LDAPv3 Replication Information Model I-D. APR 03 Revise LDAPv3 Client Update Protocol I-D. MAY 03 Revise LDAPv3 Update Reconciliation Procedures I-D. MAY 03 Revise LDAPv3 Replication Architecture I-D. MAY 03 Revise LDAPv3 Replication Information Transport Protocol I-D. MAY 03 Revise LDAPv3 Replica Management I-D. MAY 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. JUN 03 Revise LDAPv3 Replication General Usage Profile I-D. JUN 03 LDAPv3 Replication Information Model I-D goes to WG Last Call as Informational. JUN 03 LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. JUL 03 Revise LDAPv3 Update Reconciliation Procedures I-D. JUL 03 Revise LDAPv3 Replication Information Transport Protocol I-D. JUL 03 Revise LDAPv3 Replica Management I-D. JUL 03 Evaluate Deliverables Status. AUG 03 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Replica Management I-D goes to WG Last Call as Experimental. SEP 03 LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as Informational. From owner-ietf-ldup@mail.imc.org Wed Apr 9 22:51:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24064 for ; Wed, 9 Apr 2003 22:51:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A2gvJM009066 for ; Wed, 9 Apr 2003 19:42:57 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3A2gvJs009065 for ietf-ldup-bks; Wed, 9 Apr 2003 19:42:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3A2gsJM009060 for ; Wed, 9 Apr 2003 19:42:55 -0700 (PDT) Received: from D7ST2111 (pool-151-204-200-10.pskn.east.verizon.net [151.204.200.10]) by dns.caledonia.net; Wed, 09 Apr 2003 20:41:41 -0600 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: Draft LDUP WG Meeting Minutes Date: Wed, 9 Apr 2003 22:42:15 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000301c2ff0a$ccfd8dc0$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h3A2guJM009062 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Final meeting minutes are due to the proceedings editor on April 14, 2003. Please post to the mailing list or send directly to John and I, comments and corrections no later than 1700 US ET on April 13, 2003. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ========================================================================= LDAP Duplication/Replication/Update Protocols WG (ldup) Tuesday, March 18 at 1300-1400 =============================== CHAIRS: Chris Apple John Strassner Minutes taken by: John Strassner The meeting was run according to the posted agenda. The meeting minutes therefore mirror the agenda topics. 1. Consensus on a path to conclude - Chris Apple reporting It was obvious from the last meeting that we weren’t going to be able to achieve consensus to produce standards-based documents for all of the work that is listed in our current charter. After an email exchange, consensus was reached that the working group would try and move all documents forward on an experimental path. The one exception to this is the LCUP document, which is targeted at the standards track. There were no comments to this presentation. 2. Status of various documents. 2a. LDAP Client Update Protocol - Rich Megginson reporting The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt Rich opined that the draft is good as is and ready to be released, with the one exception that Kurt Zeilenga and John Young are not happy with the draft. Kurt has posted a counter draft, called LDAP Content Sync, available at the following URL: http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-01.txt First, it should be noted that the two drafts have moved closer to agreement. However, there are still significant differences between these two drafts, and the nature of the disputes are fundamental to the design of each. The disputes boil down to three points of contention. The first point of contention is that while both protocols synchronize directory information, LCUP operates within the user information model, while LDAP Content Sync operates within the system information model. An example of a facsimileTelephoneNumber implemented as a virtual or a collective attribute was used. The difference between how the two protocols operate for this example is two-fold: LCUP provides the changed data, LDAP Content Sync doesn’t. LCUP causes every entry with the collective attribute definition to be reported as modified (which could in turn cause a large number of entries to be returned to the client), while LDAP Content Sync only returns one entry. The difference in the above is that with LCUP, the client doesn’t need to know the details of the physical information model, whereas with LDAP Content Sync, the client must know the details of the physical information model. The second area of difference is that LCUP requires history to be maintained, while LDAP Content Sync doesn’t. LCUP sends one entry because it has historical data present; LDAP Content Sync sends the full requested entry if modified, or sends the DN or UUID of the entry for unchanged entries. This means that the client is responsible for deleting entries from its local store that are not returned. This in turn means that if there are N entries in the result set of the search, modifying one value will cause N messages to be sent. The final major difference is that in LCUP, changes to meta data, as well as subtree operations may either cause the client to resync, or to send a large number of messages. This is because LCUP assumes that these operations are very infrequent and therefore relatively inexpensive. LDAP Content Sync doesn’t have this side-effect because it always sends a message for every entry. Kurt stated that as designed, LCUP doesn’t meet the needs of OpenLDAP. Rich stated that the issues that Kurt is raising are beyond the original design scope of LCUP. The co-chairs recommended two action items, which were accepted by the meeting attendees: 1) Rich and Kurt should meet and try and resolve their differences by COB Friday this week. If their differences can’t be resolved, then they should report that to the working group. 2) Both drafts will need applicability statements added if they want to be progressed. The co-chairs will propose a recommended course of action based on the results of the meeting of Rich and Kurt. 2b. LDUP Update Reconciliation Procedures - Steven Legg reporting The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-07.txt Steven reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. Some minor work needs to be done to update references, and then it is ready to go. 2c. LDAP Replication Architecture - Chris Apple reporting for Uppili Srinivasan The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-08.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. Ed Reed is retiring as an author from this effort, but John Merrells and Gerry Maziarski have both volunteered to help. While the document is ready from the point-of-view of the LDUP requirements and the Mandatory Replica documents, it still has references to many issues that are outside the scope of LDUP as it is currently defined. Examples of this include access control and the administration model. Thus, the plans for finishing this document are to first ensure consistency with other LDUP documents, then to excise these other issues, and finally to do one last pass before a last call. 2d. LDUP Replication Information Model - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-06.txt This is an important draft, especially because many other documents depend on it. An update for it is promised by mid to late April. The current update was done to avoid it expiring. 2e. The LDUP Replication Update Protocol - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-04.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. It is in good shape for being released. Two actions need to be taken before that can happen: 1) Document Editor needs to complete search of mail archives to ensure that no open issues exist (currently doesn’t believe that any exist). 2) Changes to other LDUP docs that affect this document will of course cause it to change; we’ll need to see if any such changes happen or not. 2f. General Usage Profile for LDAPv3 Replication - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-04.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. The co-chairs would like to see comments on this document. One thing to think about as you comment is whether this profile is sufficient, or whether the single- and multi-master replication profiles are still needed. 2g. Mandatory LDAP Replica Management - Chris Apple reporting on behalf of the co-authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-02.txt This draft is dependent on the information model, and can’t really be updated until the Information Model is updated. It will be turned around as quick as possible once this is done. 3. WG Charter Revision/Review The only thing that has changed so far was the milestones. This is because we have established consensus on a path to conclude our work. If the co-chairs detect that there is significant slippage in these dates, then the co-chairs will most likely recommend that the working group conclude immediately. We need to discuss on the mailing list whether we need to keep the single- and multi-master profiles in the charter, or whether the general usage profile is sufficient. Kurt expressed concern over the charter wording, and would like to see "re-evaluate" changed to "conclude." Chris responded that in the past, the use of "conclude" was discouraged by the ADs. 4. Next steps Chris will revise the charter posting. The LCUP gang will get together with Kurt and report progress (or lack thereof) to the WG by this Friday (3/21). Information model draft needs to be discussed and revised as soon as possible. End of meeting. From owner-ietf-ldup@mail.imc.org Thu Apr 10 08:08:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16604 for ; Thu, 10 Apr 2003 08:08:33 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AC0tJM006545 for ; Thu, 10 Apr 2003 05:00:55 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AC0tcH006543 for ietf-ldup-bks; Thu, 10 Apr 2003 05:00:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AC0rJM006533 for ; Thu, 10 Apr 2003 05:00:54 -0700 (PDT) Received: from D7ST2111 (pool-151-204-68-121.delv.east.verizon.net [151.204.68.121]) by dns.caledonia.net; Thu, 10 Apr 2003 05:59:35 -0600 Reply-To: From: "Chris Apple" To: , , "'John McMeeking'" , "'Rich Megginson'" , , , Cc: , "John Strassner" Subject: Document Revision Due Date Reminder Date: Thu, 10 Apr 2003 08:00:04 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000c01c2ff58$bea192a0$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A revision of both the LCUP and LDUP information model documents are due according to the WG charter revision proposal before the end of the month of April 2003. Please acknowledge this message with your intended publication date to myself, John Strassner, and ietf-ldup@imc.org. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Mon Apr 14 04:34:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27963 for ; Mon, 14 Apr 2003 04:34:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E8Kw1r032585 for ; Mon, 14 Apr 2003 01:20:58 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3E8Kww2032583 for ietf-ldup-bks; Mon, 14 Apr 2003 01:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from rly-ip03.mx.aol.com (rly-ip03.mx.aol.com [64.12.138.7]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3E8Kv1r032568 for ; Mon, 14 Apr 2003 01:20:58 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from logs-ntc-tk.proxy.aol.com (logs-ntc-tk.proxy.aol.com [198.81.21.2]) by rly-ip03.mx.aol.com (v89.10) with ESMTP id RELAYIN2-0414041729; Mon, 14 Apr 2003 04:17:29 -0400 Received: from D7ST2111 (ACBF33DD.ipt.aol.com [172.191.51.221]) by logs-ntc-tk.proxy.aol.com (8.12.9/8.12.9) with ESMTP id h3E8EJsk028294; Mon, 14 Apr 2003 08:14:21 GMT Reply-To: From: "Chris Apple" To: Cc: , "John Strassner" , "Ted Hardie" , "'ned Freed'" Subject: Final LDUP WG Meeting Minutes Date: Mon, 14 Apr 2003 04:14:14 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000a01c3025d$db0a5f50$dd33bfac@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Apparently-From: Swdudephl@aol.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h3E8Kw1r032576 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit See text below. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ========================================================================= LDAP Duplication/Replication/Update Protocols WG (ldup) Tuesday, March 18 at 1300-1400 =============================== CHAIRS: Chris Apple John Strassner Minutes taken by: John Strassner The meeting was run according to the posted agenda. The meeting minutes therefore mirror the agenda topics. 1. Consensus on a path to conclude - Chris Apple reporting It was obvious from the last meeting that we weren’t going to be able to achieve consensus to produce standards-based documents for all of the work that is listed in our current charter. After an email exchange, consensus was reached that the working group would try and move all documents forward on an experimental path. The one exception to this is the LCUP document, which is targeted at the standards track. There were no comments to this presentation. 2. Status of various documents. 2a. LDAP Client Update Protocol - Rich Megginson reporting The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-04.txt Rich opined that the draft is good as is and ready to be released, with the one exception that Kurt Zeilenga and John Young are not happy with the draft. Kurt has posted a counter draft, called LDAP Content Sync, available at the following URL: http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-01.txt First, it should be noted that the two drafts have moved closer to agreement. However, there are still significant differences between these two drafts, and the nature of the disputes are fundamental to the design of each. The disputes boil down to three points of contention. The first point of contention is that while both protocols synchronize directory information, LCUP operates within the user information model, while LDAP Content Sync operates within the system information model. An example of a facsimileTelephoneNumber implemented as a virtual or a collective attribute was used. The difference between how the two protocols operate for this example is two-fold: LCUP provides the changed data, LDAP Content Sync doesn’t. LCUP causes every entry with the collective attribute definition to be reported as modified (which could in turn cause a large number of entries to be returned to the client), while LDAP Content Sync only returns one entry. The difference in the above is that with LCUP, the client doesn’t need to know the details of the physical information model, whereas with LDAP Content Sync, the client must know the details of the physical information model. The second area of difference is that LCUP requires history to be maintained, while LDAP Content Sync doesn’t. LCUP sends one entry because it has historical data present; LDAP Content Sync sends the full requested entry if modified, or sends the DN or UUID of the entry for unchanged entries. This means that the client is responsible for deleting entries from its local store that are not returned. This in turn means that if there are N entries in the result set of the search, modifying one value will cause N messages to be sent. The final major difference is that in LCUP, changes to meta data, as well as subtree operations may either cause the client to resync, or to send a large number of messages. This is because LCUP assumes that these operations are very infrequent and therefore relatively inexpensive. LDAP Content Sync doesn’t have this side-effect because it always sends a message for every entry. Kurt stated that as designed, LCUP doesn’t meet the needs of OpenLDAP. Rich stated that the issues that Kurt is raising are beyond the original design scope of LCUP. The co-chairs recommended two action items, which were accepted by the meeting attendees: 1) Rich and Kurt should meet and try and resolve their differences by COB Friday this week. If their differences can’t be resolved, then they should report that to the working group. 2) Both drafts will need applicability statements added if they want to be progressed. The co-chairs will propose a recommended course of action based on the results of the meeting of Rich and Kurt. 2b. LDUP Update Reconciliation Procedures - Steven Legg reporting The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-07.txt Steven reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. Some minor work needs to be done to update references, and then it is ready to go. 2c. LDAP Replication Architecture - Chris Apple reporting for Uppili Srinivasan The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-08.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. Ed Reed is retiring as an author from this effort, but John Merrells and Gerry Maziarski have both volunteered to help. While the document is ready from the point-of-view of the LDUP requirements and the Mandatory Replica documents, it still has references to many issues that are outside the scope of LDUP as it is currently defined. Examples of this include access control and the administration model. Thus, the plans for finishing this document are to first ensure consistency with other LDUP documents, then to excise these other issues, and finally to do one last pass before a last call. 2d. LDUP Replication Information Model - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-06.txt This is an important draft, especially because many other documents depend on it. An update for it is promised by mid to late April. The current update was done to avoid it expiring. 2e. The LDUP Replication Update Protocol - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-04.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. It is in good shape for being released. Two actions need to be taken before that can happen: 1) Document Editor needs to complete search of mail archives to ensure that no open issues exist (currently doesn’t believe that any exist). 2) Changes to other LDUP docs that affect this document will of course cause it to change; we’ll need to see if any such changes happen or not. 2f. General Usage Profile for LDAPv3 Replication - Chris Apple reporting on behalf of the authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-04.txt Chris reported that there are no technical changes to this document; it was reissued to avoid becoming obsolete. The co-chairs would like to see comments on this document. One thing to think about as you comment is whether this profile is sufficient, or whether the single- and multi-master replication profiles are still needed. 2g. Mandatory LDAP Replica Management - Chris Apple reporting on behalf of the co-authors The URL for this is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-02.txt This draft is dependent on the information model, and can’t really be updated until the Information Model is updated. It will be turned around as quick as possible once this is done. 3. WG Charter Revision/Review The only thing that has changed so far was the milestones. This is because we have established consensus on a path to conclude our work. If the co-chairs detect that there is significant slippage in these dates, then the co-chairs will most likely recommend that the working group conclude immediately. We need to discuss on the mailing list whether we need to keep the single- and multi-master profiles in the charter, or whether the general usage profile is sufficient. Kurt expressed concern over the charter wording, and would like to see "re-evaluate" changed to "conclude." Chris responded that in the past, the use of "conclude" was discouraged by the ADs. 4. Next steps Chris will revise the charter posting. The LCUP gang will get together with Kurt and report progress (or lack thereof) to the WG by this Friday (3/21). Information model draft needs to be discussed and revised as soon as possible. End of meeting. From owner-ietf-ldup@mail.imc.org Thu Apr 17 04:30:52 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12371 for ; Thu, 17 Apr 2003 04:30:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H8L1t2023570 for ; Thu, 17 Apr 2003 01:21:01 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3H8L1pb023569 for ietf-ldup-bks; Thu, 17 Apr 2003 01:21:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3H8Kvt2023555 for ; Thu, 17 Apr 2003 01:20:59 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (ACC3A585.ipt.aol.com [172.195.165.133]) by dns.caledonia.net; Thu, 17 Apr 2003 02:20:02 -0600 Reply-To: From: "Chris Apple" To: "'Ted Hardie'" , Cc: , "'John Strassner'" Subject: LDUP WG Charter Revision - Consensus Version Date: Thu, 17 Apr 2003 04:20:18 -0400 Organization: DSI-Consulting, Inc. Message-ID: <001601c304ba$30d4dab0$1dbbc7ac@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <000f01c2fe50$d5571cd0$0400a8c0@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ted & Ned, The LDUP WG members have achieved consensus on the following WG Charter Revision. This e-mail is an official request for you to review it and consider recommending its approval to the IESG. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com ---------------------------------------------------------------- LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John Strassner Applications Area Director(s): Ned Freed Ted Hardie Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. This group was originally chartered to standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Recently, the WG established consensus on a change of direction to pursue publication of a standards track protocol for LDAPv3 client synchronization, an experimental LDAPv3 replication protocol, and supporting informational documents. Thus the new work program is largely the same as the original work program with one notable exception, the LDAPv3 replication protocol is intended to be an experimental rather than a standards track protocol. The WG's approach was to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which were the domain of other working groups. Because the responsible WG failed to achieve consensus on a standard access control model for LDAPv3, the LDUP WG formed a design team to explore the issue of how to address the lack of such a model in the context of LDAPv3 replication. This design team made recommendations to the working group. The working group considered these recommendations and consensus was established on addressing these recommendations in the context of revising other working group deliverables rather than adding new deliverables specific to access control for replication. Largely because of the lack of a standard access control model for LDAPv3, the working group also established consensus on pursuing an experimental or informational publication path for a majority of working group documents formerly intended to become proposed standards. The new replication architecture supports all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Replica Management Specifications designed to support administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o A General Usage Profile of the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures. o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The work being done in the LDUP WG should be coordinated to the closest extent possible with similar work being done in the ITU. This is necessary both because LDAP depends on X.500 and because it makes sense from an operational perspective. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Architecture. Done LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Done Submit I-D on LDAPv3 Mandatory Replica Management. Done Submit I-D on LDAPv3 Replication General Usage Profile. Done LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. Done Revise LDAPv3 Client Update Protocol I-D. APR 03 Revise LDAPv3 Replication Information Model I-D. APR 03 Revise LDAPv3 Client Update Protocol I-D. MAY 03 Revise LDAPv3 Update Reconciliation Procedures I-D. MAY 03 Revise LDAPv3 Replication Architecture I-D. MAY 03 Revise LDAPv3 Replication Information Transport Protocol I-D. MAY 03 Revise LDAPv3 Replica Management I-D. MAY 03 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard. JUN 03 Revise LDAPv3 Replication General Usage Profile I-D. JUN 03 LDAPv3 Replication Information Model I-D goes to WG Last Call as Informational. JUN 03 LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. JUL 03 Revise LDAPv3 Update Reconciliation Procedures I-D. JUL 03 Revise LDAPv3 Replication Information Transport Protocol I-D. JUL 03 Revise LDAPv3 Replica Management I-D. JUL 03 Evaluate Deliverables Status. AUG 03 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Experimental. AUG 03 LDAPv3 Replica Management I-D goes to WG Last Call as Experimental. SEP 03 LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as Informational. From owner-ietf-ldup@mail.imc.org Wed Apr 30 06:41:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27996 for ; Wed, 30 Apr 2003 06:41:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UAW5i2063192 for ; Wed, 30 Apr 2003 03:32:05 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UAW5PG063191 for ietf-ldup-bks; Wed, 30 Apr 2003 03:32:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UAW3i2063186 for ; Wed, 30 Apr 2003 03:32:04 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27555; Wed, 30 Apr 2003 06:29:12 -0400 (EDT) Message-Id: <200304301029.GAA27555@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-lcup-05.txt Date: Wed, 30 Apr 2003 06:29:11 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Client Update Protocol Author(s) : R. Megginson, M. Smith, O. Natkovich, J. Parham Filename : draft-ietf-ldup-lcup-05.txt Pages : 27 Date : 2003-4-29 This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ldup-lcup-05.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-ietf-ldup-lcup-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-29164424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-lcup-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-lcup-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-29164424.I-D@ietf.org> --OtherAccess-- --NextPart--