From owner-ietf-ldup@imc.org Wed Mar 1 02:18:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24325 for ; Wed, 1 Mar 2000 02:18:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA11130 for ietf-ldup-bks; Tue, 29 Feb 2000 22:38:42 -0800 (PST) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11124 for ; Tue, 29 Feb 2000 22:38:41 -0800 (PST) Received: from master.control.att.com (master.control.att.com [135.207.251.13]) by dir1.control.att.com (Postfix) with SMTP id C67B771F8; Wed, 1 Mar 2000 01:38:43 -0500 (EST) Date: Wed, 1 Mar 2000 01:38:42 -0500 (EST) From: Chris Apple To: ietf-ldup@imc.org Cc: paf@swip.net, moore@cs.utk.edu, johns@cisco.com Subject: Proposed LDUP WG Agenda... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ....and a healthy nudge from the chairs to get all committed documents revised or published prior to March 10th (the I-D Cut-Off date). We're requesting a 2 hour meeting slot at Adelaide. Due to work conditions, I may or may not be able to attend myself. However, John Strassner will be there for sure. See the IETF Web Site (http://www.ietf.org) for current WG Charter. Short story: we're behind. Again. Longer story is weaved into the proposed agenda. Please read and react appropriately. :) If you've been unable to revise your document as agreed at the last IETF meeting or haven't published a document as committed in the charter. Please do so by March 10th. Proposed LDUP WG Meeting Agenda - Adelaide - March 2000 1) Agenda Bashing 2) Why are we so far behind? We're showing the signs of starting to die a flailing death. Don't let it happen if this work is important for your LDAP implementations. Working groups have, can, and will be killed for lack of activity similar to what I've seen since the last IETF meeting. 3) LDAP Replication Architecture (98749 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-02.txt References to other WG deliverables are to be removed per joint recommendation of the WG Chairs and the Applications Area Directors. This document is supposed to stand on its own and not be held up waiting for other deliverables to clear IESG Review, IETF Last Call, and the RFC Editor. 4) LDAP V3 Replication Requirements (34050 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-02.txt Ready for IESG Review? 5) LDUP Replication Information Model (37772 bytes) http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-00.txt Was to go through WG Last Call a while ago. We doubt its ready at current revision number. Was supposed to have been revised prior to WG Last Call Milestone Date. 6) LDUP Update Reconciliation Procedures (62250 bytes) draft-ietf-ldup-urp-02.txt Ready for WG Last Call? 7) LDAP Subentry Schema (8684 bytes) draft-ietf-ldup-subentry-01.txt Should this be merged with Replication Information Model document? 8) The LDUP Replication Update Protocol (31316 bytes) draft-ietf-ldup-protocol-00.txt Probably needs one more revision before WG Last Call. 9) Drafts that are missing in action or how long do you think it will be before the WG concludes prematurely if we don't get these published? LDAPv3 Mandatory Replica Management I-D LDAPv3 Master-Slave Replication Profile I_D LDAPv3 Multi-Master Replication Profile I-D 10) Discuss addition of LCUP work items to end of Charter. ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup@imc.org Wed Mar 1 07:08:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28753 for ; Wed, 1 Mar 2000 07:08:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25318 for ietf-ldup-bks; Wed, 1 Mar 2000 03:32:49 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA25313 for ; Wed, 1 Mar 2000 03:32:48 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 01 Mar 2000 04:32:10 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 01 Mar 2000 04:31:54 -0700 From: "Natarajan SK" To: , Cc: "Savitha R" Subject: Changelog entries draft. Do not seem to find it. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA25315 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi , The draft-ietf-ldup-replica-req-02.txt ( LDAP V3 Replication Requirements ) draft specifies as a reference : [Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP Change records", Internet Draft, draft-ietf-asid-changelog- 00.txt, November 1996. I do not seem to find the draft anywhere. Could anyone help? Also is there any written material on LDAP changelogs otherwise? Aprpeciate anybody who can help. Regards, Natarajan S.K.Natarajan Senior Software Engineer Novell Software, Bangalore E-mail sknatarajan@novell.com Ph. no. 91-80-572-1856/58 Extn. 2213 Fx 91-80-572-1870 From owner-ietf-ldup@imc.org Wed Mar 1 13:40:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10247 for ; Wed, 1 Mar 2000 13:40:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05953 for ietf-ldup-bks; Wed, 1 Mar 2000 10:06:11 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05949 for ; Wed, 1 Mar 2000 10:06:10 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA06334 for ; Wed, 1 Mar 2000 10:03:39 -0800 (PST) Received: from netscape.com ([208.12.63.184]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQR8XN00.FFP; Wed, 1 Mar 2000 10:05:47 -0800 Message-ID: <38BD5BA9.57715393@netscape.com> Date: Wed, 01 Mar 2000 10:04:25 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Natarajan SK CC: ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The changelog draft has expired. I believe that the reference to the changelog draft should be removed from the LDUP requirements document. The reference is made in passing, and (incorrectly) implies that the changelog draft is part of the core LDAP specifications (which it is not). Quoting from draft-ietf-ldup-replica-req-02.txt: "Currently LDAP does not define a replication mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog]) in passing. The requirements for replication are critical to the successful deployment and acceptance of LDAP in the market place." Removing the reference to [Changelog] would allow the replication requirements draft to proceed without any dependency on the changelog draft. While I'm happy to resurrect the changelog draft and discuss publishing it as a standards-track document (informational, probably), it's not going to be a part of the LDUP specification. -Gordon Natarajan SK wrote: > Hi , > The draft-ietf-ldup-replica-req-02.txt ( LDAP V3 Replication Requirements ) > draft specifies as a reference : > > [Changelog] Gordon Good, "Definitions of an Object Class to Hold > LDAP Change records", Internet Draft, draft-ietf-asid-changelog- > 00.txt, November 1996. > > I do not seem to find the draft anywhere. Could anyone help? Also is there any written material on LDAP changelogs otherwise? > > Aprpeciate anybody who can help. > > Regards, > Natarajan > > S.K.Natarajan > Senior Software Engineer > Novell Software, Bangalore > E-mail sknatarajan@novell.com > Ph. no. 91-80-572-1856/58 Extn. 2213 > Fx 91-80-572-1870 From owner-ietf-ldup@imc.org Wed Mar 1 14:03:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10636 for ; Wed, 1 Mar 2000 14:03:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06422 for ietf-ldup-bks; Wed, 1 Mar 2000 10:30:05 -0800 (PST) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06418 for ; Wed, 1 Mar 2000 10:30:03 -0800 (PST) Received: from gypsy (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with SMTP id SAA76366; Wed, 1 Mar 2000 18:29:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <3.0.5.32.20000301102956.0093fea0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 01 Mar 2000 10:29:56 -0800 To: ggood@netscape.com (Gordon Good) From: "Kurt D. Zeilenga" Subject: Re: Changelog entries draft. Do not seem to find it. Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org In-Reply-To: <38BD5BA9.57715393@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:04 AM 3/1/00 -0800, Gordon Good wrote: >While I'm happy to resurrect the changelog draft and discuss publishing it as a standards-track document (informational, >probably), it's not going to be a part of the LDUP specification. I would support publication of the Changelog draft as an Informational RFC as it would document existing practices. The document would have to be amended, of course, to contain appropriate statements concerning IETF work in this area. Kurt From owner-ietf-ldup@imc.org Wed Mar 1 17:33:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15098 for ; Wed, 1 Mar 2000 17:33:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09637 for ietf-ldup-bks; Wed, 1 Mar 2000 14:05:01 -0800 (PST) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09632 for ; Wed, 1 Mar 2000 14:05:00 -0800 (PST) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id 0C08D71F6; Wed, 1 Mar 2000 17:05:08 -0500 (EST) Message-ID: <38BD944B.6E26C1BC@att.com> Date: Wed, 01 Mar 2000 17:06:03 -0500 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Good Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: <38BD5BA9.57715393@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lets just remove it. Chris. Gordon Good wrote: > > The changelog draft has expired. > > I believe that the reference to the changelog draft should be removed from the LDUP requirements document. The reference is made > in passing, and (incorrectly) implies that the changelog draft is part of the core LDAP specifications (which it is not). Quoting > from draft-ietf-ldup-replica-req-02.txt: > > "Currently LDAP does > not define a replication mechanism and only generally mentions LDAP > shadow servers (see [RFC2251] and [Changelog]) in passing. The > requirements for replication are critical to the successful > deployment and acceptance of LDAP in the market place." > > Removing the reference to [Changelog] would allow the replication requirements draft to proceed without any dependency on the > changelog draft. > > While I'm happy to resurrect the changelog draft and discuss publishing it as a standards-track document (informational, > probably), it's not going to be a part of the LDUP specification. > > -Gordon > > Natarajan SK wrote: > > > Hi , > > The draft-ietf-ldup-replica-req-02.txt ( LDAP V3 Replication Requirements ) > > draft specifies as a reference : > > > > [Changelog] Gordon Good, "Definitions of an Object Class to Hold > > LDAP Change records", Internet Draft, draft-ietf-asid-changelog- > > 00.txt, November 1996. > > > > I do not seem to find the draft anywhere. Could anyone help? Also is there any written material on LDAP changelogs otherwise? > > > > Aprpeciate anybody who can help. > > > > Regards, > > Natarajan > > > > S.K.Natarajan > > Senior Software Engineer > > Novell Software, Bangalore > > E-mail sknatarajan@novell.com > > Ph. no. 91-80-572-1856/58 Extn. 2213 > > Fx 91-80-572-1870 -- ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup@imc.org Thu Mar 2 04:17:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09028 for ; Thu, 2 Mar 2000 04:17:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA04544 for ietf-ldup-bks; Thu, 2 Mar 2000 00:40:40 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04539 for ; Thu, 2 Mar 2000 00:40:38 -0800 (PST) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.9.3/8.9.3) with ESMTP id JAA07514; Thu, 2 Mar 2000 09:40:46 +0100 (MET) Received: from pappel.mch.sni.de (pappel.mch.sni.de [139.23.81.148]) by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id JAA07928; Thu, 2 Mar 2000 09:40:46 +0100 (MET) Received: by pappel.mch.sni.de with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 09:40:45 +0100 Message-ID: From: "Volpers, Helmut" To: "'ietf-lcup@netscape.com'" , "'LDUP'" Subject: RE: LDAP Client Update Protocol Date: Thu, 2 Mar 2000 09:40:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I didn't receive any mail in the last months on this list. Is ldup still in discussion ? Is lcup an issue where anyone is working on ? Exists other distribution lists for ldap replication ? Will there be a discussion in Adelhaide ? Helmut From owner-ietf-ldup@imc.org Thu Mar 2 09:17:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13373 for ; Thu, 2 Mar 2000 09:17:12 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA21514 for ietf-ldup-bks; Thu, 2 Mar 2000 05:37:16 -0800 (PST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21510 for ; Thu, 2 Mar 2000 05:37:14 -0800 (PST) Received: from zcard015.ca.nortel.com (actually zcard015) by smtprtp1.ntcom.nortel.net; Thu, 2 Mar 2000 08:32:33 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 08:32:32 -0500 Message-ID: <438D12915E64D2118AB10000F8C1C07802734093@zcard00e.ca.nortel.com> From: "James Benedict" To: "Kurt D. Zeilenga" , ggood@netscape.com Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 08:32:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF844B.C324378C" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF844B.C324378C Content-Type: text/plain; charset="ISO-8859-1" Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > ------_=_NextPart_001_01BF844B.C324378C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Changelog entries draft. Do not seem to find it.

Changelogs seem to be falling between the cracks = (LDAP, LDUP,
LCUP?).  The concept of changelogs is important = to replication, but it also has many other uses.

Accountability (Who did what? When?)
Problem Tracking (Why is my email address X)
Recovery (Whoops, I didn't really want to rename = everyone in my directory)
Client-side caching (Give me all the changes to a = subtree)

If LDUP is going to subsume the role of maintaining = changes for replication
purposes, then I think it is important to make sure = that mechanisms are
in place to deal with these other uses as = well.  Otherwise, I think
changelogs should become part of the LDAP standard, = not just informational.

It doesn't really matter how the directory server = maintains this information, but clients need to have a consistent way = of accessing it.

James A Benedict
Advisor, IP Directory Systems Architecture
Preside Policy Services
NORTEL NETWORKS
Ph:  (613) 763-3909


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, March 01, 2000 1:30 PM
> To: ggood@netscape.com
> Cc: Natarajan SK; ietf-ldapext@netscape.com; = Savitha R;
> ietf-ldup@imc.org
> Subject: Re: Changelog entries draft. Do not = seem to find it.
>
>
> At 10:04 AM 3/1/00 -0800, Gordon Good = wrote:
> >While I'm happy to resurrect the changelog = draft and discuss
> publishing it as a standards-track document = (informational,
> >probably), it's not going to be a part = of  the LDUP specification.
>
> I would support publication of the Changelog = draft as an
> Informational RFC as it would document existing = practices.
> The document would have to be amended, of = course, to contain
> appropriate statements concerning IETF work in = this area.
>
> Kurt
>

------_=_NextPart_001_01BF844B.C324378C-- From owner-ietf-ldup@imc.org Thu Mar 2 10:03:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14316 for ; Thu, 2 Mar 2000 10:03:34 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA23194 for ietf-ldup-bks; Thu, 2 Mar 2000 06:12:40 -0800 (PST) Received: from lsmls01.we.mediaone.net (lsmls01.we.mediaone.net [24.130.1.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23184 for ; Thu, 2 Mar 2000 06:12:37 -0800 (PST) Received: from fiddle (we-24-30-124-12.we.mediaone.net [24.30.124.12]) by lsmls01.we.mediaone.net (8.8.7/8.8.7) with SMTP id GAA03554; Thu, 2 Mar 2000 06:12:26 -0800 (PST) From: "Howard Chu" To: "James Benedict" , "Kurt D. Zeilenga" , Cc: "Natarajan SK" , , "Savitha R" , Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 06:14:31 -0800 Message-ID: <000201bf8451$a0e2d1a0$0c01a8c0@fiddle.symas.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01BF840E.92BF91A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <438D12915E64D2118AB10000F8C1C07802734093@zcard00e.ca.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0003_01BF840E.92BF91A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Changelog entries draft. Do not seem to find it.The ChangeLog spec isn't sufficient for "Accountability" purposes. It isn't flexible enough to provide a full audit of all operations; since it only records successful changes it doesn't address binds, searches, compares, etc... It doesn't record who did an operation. The changeNumber mechanism is problematic. I started talking to Gordon about using it for these purposes, but after he pointed out its limitations I decided to let it drop. I came up with something similar for our own audit log purposes. If you're interested, here's a quick summary: requestId: ; requestUser: the bindDN that was in effect, or "(anonymous)" requestDn: the DN of interest to the operation, if any requestType: add/bind/compare/delete/etc... requestResult: numeric result code [, number of results returned by search] requestParameters: free format field. For a typical search, this could contain e.g. scope: 2 filter: (objectclass=*) attrs: objectclass attrs: cn The requestParameters attribute gets treated as a binary object... I have auditing configured both globally and on a per-subtree (slapd backend) basis, with "audit (none|mod|all)" - "audit mod" is essentially just a changelog, "audit all" adds bind, compare, search, and unbind. (Sorry, y'all probably aren't interested in implementation details here, but it seemed like a simple example was warranted.) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -----Original Message----- From: James Benedict [mailto:grunt@nortelnetworks.com] Sent: Thursday, March 02, 2000 5:32 AM To: Kurt D. Zeilenga; ggood@netscape.com Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > ------=_NextPart_000_0003_01BF840E.92BF91A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Changelog entries draft. Do not seem to find = it.
The=20 ChangeLog spec isn't sufficient for "Accountability" purposes. It isn't = flexible=20 enough to provide a full audit of all operations; since it only records=20 successful changes it doesn't address binds, searches, compares, etc... = It=20 doesn't record who did an operation. The changeNumber mechanism is = problematic.=20 I started talking to Gordon about using it for these purposes, but after = he=20 pointed out its limitations I decided to let it drop. I came up with = something=20 similar for our own audit log purposes.
 
If=20 you're interested, here's a quick summary:
 =20 requestId: <timestamp>;<sequence number>
 =20 requestUser: the bindDN that was in effect, or = "(anonymous)"
 =20 requestDn: the DN of interest to the operation, if = any
 =20 requestType: add/bind/compare/delete/etc...
 =20 requestResult: numeric result code [, number of results returned by=20 search]
 =20 requestParameters: free format field. For a typical search, this could = contain=20 e.g.
     scope: = 2
     filter:=20 (objectclass=3D*)
     attrs:=20 objectclass
     attrs: = cn
The=20 requestParameters attribute gets treated as a binary=20 object...
 
I have=20 auditing configured both globally and on a per-subtree (slapd backend) = basis,=20 with "audit (none|mod|all)" - "audit mod" is essentially just a = changelog,=20 "audit all" adds bind, compare, search, and unbind. (Sorry, y'all = probably=20 aren't interested in implementation details here, but it seemed like a = simple=20 example was warranted.)

  -- Howard Chu
  Chief Architect, Symas=20 Corp.       Director, Highland = Sun
  http://www.symas.com     &nb= sp;        =20 http://highlandsun.com/hyc

 
-----Original Message-----
From: James Benedict=20 [mailto:grunt@nortelnetworks.com]
Sent: Thursday, March 02, = 2000=20 5:32 AM
To: Kurt D. Zeilenga; = ggood@netscape.com
Cc:=20 Natarajan SK; ietf-ldapext@netscape.com; Savitha R;=20 ietf-ldup@imc.org
Subject: RE: Changelog entries draft. Do = not seem=20 to find it.

Changelogs seem to be falling between the cracks = (LDAP, LDUP,=20
LCUP?).  The concept of changelogs is = important=20 to replication, but it also has many other uses.

Accountability (Who did what? When?) =
Problem Tracking (Why is my email address X)
Recovery (Whoops, I didn't really want to rename everyone in = my=20 directory)
Client-side caching (Give me all = the=20 changes to a subtree)

If LDUP is going to subsume the role of maintaining = changes=20 for replication
purposes, then I think it is = important=20 to make sure that mechanisms are
in place to = deal with=20 these other uses as well.  Otherwise, I think
changelogs should become part of the LDAP standard, not just=20 informational.

It doesn't really matter how the directory server = maintains=20 this information, but clients need to have a consistent way of = accessing=20 it.

James A Benedict
Advisor, = IP Directory=20 Systems Architecture
Preside Policy = Services=20
NORTEL NETWORKS
Ph:  = (613)=20 763-3909


> -----Original Message-----
>=20 From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] =
> Sent: Wednesday, March 01, 2000 1:30 PM
> To: ggood@netscape.com
> = Cc: Natarajan=20 SK; ietf-ldapext@netscape.com; Savitha R;
>=20 ietf-ldup@imc.org
> Subject: Re: = Changelog entries=20 draft. Do not seem to find it.
> =
>
> At 10:04 AM 3/1/00 -0800, = Gordon Good=20 wrote:
> >While I'm happy to resurrect = the=20 changelog draft and discuss
> publishing = it as a=20 standards-track document (informational,
>=20 >probably), it's not going to be a part of  the LDUP=20 specification.
>
> I=20 would support publication of the Changelog draft as an =
> Informational RFC as it would document existing = practices.=20
> The document would have to be amended, of = course, to=20 contain
> appropriate statements = concerning IETF=20 work in this area.
>
>=20 Kurt
> =

------=_NextPart_000_0003_01BF840E.92BF91A0-- From owner-ietf-ldup@imc.org Thu Mar 2 11:07:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16348 for ; Thu, 2 Mar 2000 11:07:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA24918 for ietf-ldup-bks; Thu, 2 Mar 2000 07:22:11 -0800 (PST) Received: from PMESMTP02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24914 for ; Thu, 2 Mar 2000 07:22:10 -0800 (PST) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FQS0045DVQS8X@firewall.mcit.com> for ietf-ldup@imc.org; Thu, 2 Mar 2000 15:16:04 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id PAA09957; Thu, 02 Mar 2000 15:16:06 +0000 (GMT) Received: from csp06121.mcit.com ([166.37.60.22]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000302150102.MTCB13043@csp06121.mcit.com>; Thu, 02 Mar 2000 15:01:02 +0000 Received: by csp06121.mcit.com with Microsoft Mail id <01BF841C.B3228D40@csp06121.mcit.com>; Thu, 02 Mar 2000 07:55:38 -0700 Date: Thu, 02 Mar 2000 07:55:37 -0700 From: Linda Grimaldi Subject: RE: Changelog entries draft. Do not seem to find it. To: "'James Benedict'" , "Kurt D. Zeilenga" , "ggood@netscape.com" Cc: Natarajan SK , "ietf-ldapext@netscape.com" , Savitha R , "ietf-ldup@imc.org" Message-id: <01BF841C.B3228D40@csp06121.mcit.com> MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA24915 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Just one note on changelog standardization. I recently wrote a program to monitor change logs for audit purposes. It worked great on Innosoft- I had to re-write chunks of it for Netscape. I was quite pissed off, and cursed both the IETF and the LDAP working group for about a week (fortunately, to no effect). Mr. Benedict makes a good point about using the logs for other purposes. From a developer's perspective, I would really appreciate some consistency here. Linda -----Original Message----- From: James Benedict [SMTP:grunt@nortelnetworks.com] Sent: Thursday, March 02, 2000 6:32 AM To: Kurt D. Zeilenga; ggood@netscape.com Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > << File: ATT00002.htm >> From owner-ietf-ldup@imc.org Thu Mar 2 13:14:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21689 for ; Thu, 2 Mar 2000 13:14:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27369 for ietf-ldup-bks; Thu, 2 Mar 2000 09:27:09 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA27365 for ; Thu, 2 Mar 2000 09:27:08 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 02 Mar 2000 10:26:49 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 02 Mar 2000 10:26:43 -0700 From: "Jim Sermersheim" To: , , Cc: , , "Savitha R" , "Natarajan SK" Subject: RE: Changelog entries draft. Do not seem to find it. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA27366 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit LDUP/LCUP should include include enough functionality to achieve a client-side cache. For the other three issues you mention, maybe someone should author an audit draft. Jim >>> "James Benedict" 3/2/00 6:38:35 AM >>> Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > From owner-ietf-ldup@imc.org Thu Mar 2 13:41:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22467 for ; Thu, 2 Mar 2000 13:41:05 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA27342 for ietf-ldup-bks; Thu, 2 Mar 2000 09:25:17 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27338 for ; Thu, 2 Mar 2000 09:25:16 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA00183 for ; Thu, 2 Mar 2000 09:22:49 -0800 (PST) Received: from netscape.com ([207.1.151.46]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FQT1PM00.JW3; Thu, 2 Mar 2000 09:24:58 -0800 Message-ID: <38BEA3FF.509BC2AA@netscape.com> Date: Thu, 02 Mar 2000 09:25:19 -0800 From: olga@netscape.com (Olga Natkovich) X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-lcup@netscape.com CC: ietf-ldup@imc.org Subject: lcup, the first draft References: Content-Type: multipart/mixed; boundary="------------0A872BAA667F89A0A0481EFC" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0A872BAA667F89A0A0481EFC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Attached is the first draft of lcup specification. The draft will be submitted to IETF next week. Questions and comments are appreciated. Olga Natkovich Software Engineer, Sun-Netscape Alliance --------------0A872BAA667F89A0A0481EFC Content-Type: text/plain; charset=us-ascii; name="draft-natkovich-ldap-lcup-00.txt" Content-Disposition: inline; filename="draft-natkovich-ldap-lcup-00.txt" Content-Transfer-Encoding: 7bit Internet Draft O. Natkovich Document: M. Smith Category: Proposed Standard Netscape Communications Corp. February 2000 LDAP Client Update Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document defines the 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. 2. Conventions used in this document In the protocol flow definition, the notation C->S and S->C specifies the direction of the data flow from the client to the server and from the server to the client respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. 3. Overview The LCUP protocol is intended to allow LDAP clients to synchronize with the content stored by LDAP servers. The problem areas addressed by the protocol include: - mobile clients that maintain a local read-only copy of the directory data. While off-line, the client uses the local copy of the data. When the client connects to the network, it synchronizes with the current directory content and can be optionally notified about the changes that occur while it is on- line. For example, a mail client can maintain a local copy of the corporate address book that it synchronizes with the master copy whenever the client gets connected to the corporate network. - applications intending to synchronize heterogeneous data stores. A meta directory application, for instance, would periodically retrieve a list of modified entries from the directory, construct the changes and apply them to a foreign data store. - clients that need to take certain actions when a directory entry is modified. For instance, an electronic mail repository may want to perform a "create mailbox" task when a new person entry is added to an LDAP directory and a "delete mailbox" task when a person entry is removed. The problem areas not being considered: - directory server to directory server synchronization. The LDUP replication protocol [LDUPPROT] should be used for this purpose. Several features of the protocol distinguish it from LDUP replication. First, the server does not maintain any state information on behalf of its clients. The clients are responsible for storing the information about how up to date they are with respect to the server's content. Second, no predefined agreements exist between the clients and the servers. The client decides when and from where to retrieve the changes. Finally, the server never pushes the data to the client; the client always initiates the update session during which it pulls the changes from the server. The set of clients that are allowed to synchronize with an LDAP server is determined by the server defined policy. There are, currently, several protocols available for LDAP client server synchronization. While each protocol addresses the needs of a particular group of clients (on-line clients in case of Persistent [PSEARCH] and Triggered [TSEARCH] Search, off-line clients in case of DirSync [DIRSYNC]), none satisfies the requirements of all clients in the target group. For instance, a mobile client that was off-line and wants to become up to date with the server and stay up to date while connected can't be easily supported by any of the above protocols. 4. Protocol Specification This section describes the protocol elements and the protocol flow. 4.1 Protocol Elements Natkovich Proposed Standard - Expires: August 2000 2 A client initiates a synchronization session with a server by attaching a clientUpdate control to a search operation. The search specification determines the part of the directory information tree (DIT) the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. The clientUpdate control contains the client's synchronization specification. The control has the following format: clientUpdateControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL keepConnection BOOLEAN DEFAULT FALSE changesOnly BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. keepConnection - if set to TRUE, indicates that the server should keep the connection open after the initial synchronization and should notify the client of modifications to the data. The connection should stay open until the client abandons the search operation, sends the stopClientUpdate extended operation, or closes the connection. changesOnly - if set to TRUE, the keepConnection and cookie fields of the control are ignored by the server. In response, the server skips the initial synchronization and only notifies the client about the changes that occur to the data while the client is connected. This feature is useful if the client is not interested in data synchronization but needs to trigger events in response to data modifications. In response to the client's synchronization request, the server returns a set of SearchResultEntries that fits the client's specification. To represent deleted entries, the server attaches an entryUpdate control to the SearchResultEntry. Furthermore, the server may elect to periodically return to the client the cookie that represents the state of the client's data. This information is useful in case the client crashes or gets disconnected. The cookie is also provided in the entryUpdate control. The control has the following format: entryUpdateControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL stateUpdate BOOLEAN DEFAULT FALSE entryDeleted BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. stateUpdate - if set to TRUE, indicates that the entry to which the control is attached contains no changes and it is sent only to Natkovich Proposed Standard - Expires: August 2000 3 communicate to the client the new cookie. In this case, the entryDeleted field MUST be ignored and the cookie field WILL contain the updated cookie. This feature allows updating the client's cookie when there is no changes that effect the client's data store. Note that the server MUST attach the control to a valid entry. The server COULD always send the entry at the root of the client's tree. entryDeleted - if set to TRUE, indicates that the entry to which the control is attached was deleted. When the server has finished processing the client's request, it attaches a clientUpdateDone control to the SearchResult message and sends it to the client. The control has the following format: clientUpdateDoneControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL reload BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. reload - if set to TRUE, indicates that the server does not contain sufficient information to synchronize the client or that the server's data was reloaded since the last synchronization session. This field indicates to the client that the client's data store needs to be reinitialized. If the client needs to terminate the synchronization process and it wishes to obtain the cookie that represents the current state of its data, it issues a stopClientUpdateRequest extended operation. The operation carries no data. The server responds with a stopClientUpdateResponse extended operation that has the following format: stopClientUpdateResponseValue ::= SEQUENCE { cookie OCTET STRING } cookie - an opaque cookie that represents the current state of the client's data. If the client is not interested in the state information, it can simply abandon the search operation or disconnect from the server. If server resources become tight, the server can terminate one or more search operations by sending a SearchResult message to the client(s). Unless the client sets the changesOnly field to TRUE, the server attaches a clientUpdateDone control that contains the cookie that corresponds to the current state of the client's data and the reload flag set to 0. A server set policy is used to decide which searches to terminate. This can also be used as a security Natkovich Proposed Standard - Expires: August 2000 4 mechanism to disconnect clients that are suspected of malicious actions. 4.2 Protocol Flow The client server interaction can proceed in three different ways depending on the client's requirements. If the client's intent is not to synchronize data but to trigger actions in response to directory modifications, the protocol proceeds as follows: C->S Sends a search operation with a clientUpdate control attached. The search specification determines the part of the DIT the client wishes to synchronize with and the set of attributes it is interested in. The changesOnly field of the control should be set to TRUE; other fields are ignored. S->C Sends change notification to the client for each change to the data within the client's search specification. S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server can terminate the search operation by sending a SearchResult message to the client. C->S Abandons the search operation or disconnects from the server. S->C Stops sending changes to the client and closes the connection. If the client's intent is to synchronize with the server and then disconnect, the protocol proceeds as follows: C->S Sends a search operation with the clientUpdate control attached. The search specification determines the part of the DIT the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. If this is the initial synchronization session, the client does not provide a cookie; otherwise, the cookie field of the control is set to the cookie received from the server at the end of the last synchronization session. (Note that the client can synchronize with different servers during different synchronization sessions.) The keepConnection and changesOnly fields are set to FALSE. S->C If no cookie is specified in the clientUpdate control, the server sends all data that matches the client's search specification followed by the SearchResult message with a clientUpdateDone control attached to it. The control contains the cookie that corresponds to the current state of the client's data and the reload flag set to FALSE. If an invalid cookie is specified the server sends back an unwillingToPerform error. If a valid cookie is specified and the data that matches the search specification has been reloaded or the server does not contain enough state information to synchronize the client, the server sends a clientUpdateDone control with the reload field set to TRUE and no cookie. Natkovich Proposed Standard - Expires: August 2000 5 If the client is up to date, the server sends a success response to the client. If the cookie is valid and there is data to be sent, the server sends the modified entries to the client. Each SearchResultEntry contains the attributes requested by the client in the search specification regardless of whether they were modified. An entryUpdate control with the entryDeleted field set to TRUE is attached to every deleted entry. The server may also periodically attach an entryUpdate control to the entries sent to the client to indicate the current state of the client's data. In that case, the cookie field of the control represents the state of the client's data including the entry to which the control is attached. Once all the changes are sent, the server sends a SearchResult with the clientUpdateDone control attached. The control contains the cookie that represents the current state of the client's data. The reload field of the control is set to FALSE. C->S If the reload field of the control is set to TRUE, the client clears its data store and repeats the synchronization process by sending the search operation with clientUpdate control that contains no cookie. Otherwise, the client stores the cookie received from the server until the next synchronization session. If the client's intent is to be synchronized with the server and stay notified about data modifications, the protocol proceeds as follows: C->S The client behaves exactly as in the previous case except it sets the keepConnection control field to TRUE. S->C The server behaves exactly as in the previous case except the connection is kept open after the initial set of changes is sent to the client. A SearchResult message is not sent to the client; instead, the server keeps sending changes to the client. S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server can terminate the search operation by sending a SearchResult message with the clientUpdateDone control back to the client. C->S Sends a stopClientUpdateRequest extended operation to the server to terminate the synchronization session. S->C Responds with a stopClientUpdateResponse extended operation with the cookie representing the current state of the client's data. 4.3 Size and Time Limits The search request size or the time limits can only be imposed for non-persistent operations, those that set keepConnection field of the clientUpdateControlValue to FALSE. All other operations SHOULD set both limits to 0. The server SHOULD ignore the limits set for persistent operations. 4.4 Changes vs. Operations Natkovich Proposed Standard - Expires: August 2000 6 Since the server sends to the client the modified entries rather than the operations, a MODDN operation performed on a subtree will be seen by the client as a sequence of added or modified entries depending on whether the operation moved the entries into the scope of the client's search specification. 5.0 Additional Features There are several features present in other protocols or considered useful by clients that are currently not included in the protocol primarily because they are difficult to implementing on the server. These features are briefly discussed in this section. This section is intended to open a discussion on the merits of including and approaches of implementing these features. 5.1. Change Type This feature is present in the Triggered Search [TSEARCH] specification. A flag is attached to each entry returned to the client indicating the reason why this entry is returned. The possible reasons from the draft are "- notChange: the entry existed in the directory and matched the search at the time the operation is being performed, - enteredSet: the entry entered the result set for one of the reasons defined in section 4 above, - leftSet: the entry left the result set for one of the reasons defined in section 4 above, - modified: the entry was part of the result set, was modified or renamed, and still is in the result set." The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the server. This is easier to accomplish because the decision about the change type can be made based only on the change without need for any historical information. This, however, would add complexity to the protocol. 5.2. Sending Changes The DirSync protocol [DIRSYNC] sends to the clients only the modified attributes of the entry rather than the entire entry. While this approach can significantly reduce the amount of data returned to the client, it has several disadvantages. First, unless a separate mechanism (like the change type described above) is used to notify the client about entries moving into the search scope, Natkovich Proposed Standard - Expires: August 2000 7 sending only the changes can result in the client having an incomplete version of the data. Let's consider an example. An attribute of an entry is modified. As a result of the change, the entry enters the scope of the client's search. If only the changes are sent, the client would never see the initial data of the entry. Second, this feature is hard to implement since the server might not contain sufficient information to construct the changes based solely on the server's state and the client's cookie. On the other hand, this feature can be easily implemented by the client assuming that the client has the previous version of the data and can perform value by value comparisons. 5.3. Data Size Limits The DirSync protocol [DIRSYNC] allows clients to control the amount of data sent to them in the search response. The client can specify the number of bytes it is willing to receive by setting the maxReturnLength field of the DirSync control. This feature is intended to allow clients with limited resources to process synchronization data in batches. However, an LDAP search operation already provides the means for the client to specify the size limit by setting the sizeLimit field in the SearchRequest to the maximum number of entries the client is willing to receive. While the granularity is not the same, the assumption is that LCUP protocol will be implemented by regular LDAP clients that can deal with the limitations of the LDAP protocol. 5.4. Data Ordering The DirSync protocol [DIRSYNC] allows a client to specify that parent entries should be sent before the children for add operations and children entries sent before their parents during delete operations. This ordering helps clients to maintain a hierarchical view of the data in their data store. While possibly useful, this feature is relatively hard to implement and is expensive to perform. 6. The Protocol and the LDUP Architecture The LDAP Client Update Protocol is defined within the framework of the LDUP Architecture [LDUPARCH]. The following aspects of the protocol are drawn from the architecture: - The scope of each search operation is restricted to a single replica as defined in the LDUP architecture document [LDUPARCH]. - Each entry returned to the client contains a unique identifier as defined in the LDUP architecture document [LDUPARCH]. The client can use the identifier to unambiguously cross reference objects stored on the server with those in the client's store. - One of the main criteria for selecting the protocol features is that an LDUP compliant server can implement these features efficiently. Natkovich Proposed Standard - Expires: August 2000 8 7. Client Side Considerations There are several issues that the implementors of a synchronization client need to consider: - The cookie received from the server after a synchronization session can only be used with the same or more restrictive search specification than the search that generated the cookie. The server will reject the search operation with a cookie that does not satisfy this condition. This is because the client can end up with an incomplete data store otherwise. A more restrictive search specification is the one that generates a subset of the data produced by the original search specification. - Because an LCUP client specifies the area of the tree with which it wishes to synchronize through the standard LDAP search specification, the client can be returned nsSuchObject error if the root of the synchronization area was renamed between the synchronization sessions. If this condition occurs, the client can attempt to locate the root by using the root's uniqueid saved in client's local data store. It then can repeat the synchronization request using the new search base. In general, a client can detect that an entry was renamed and apply the changes received to the right entry by using uniqueid rather than DN based addressing. 8. Server Implementation Considerations By design, the protocol does not specify the format of the cookie. This is to allow different implementations the flexibility of storing any information applicable to their environment. A reasonable implementation for an LDUP compliant server would be to use the Replica Update Vector (RUV). For each master, RUV contains the largest CSN seen from this master. In addition, the RUV implemented by the iPlanet Directory Server (not yet in LDUP) contains replica generation - an opaque string that identifies the replica's data store. The replica generation value changes whenever the replica's data is reloaded. Replica generation is intended to signal the replication/synchronization peers that the replica's data was reloaded and that all other replicas need to be reinitialized. RUV satisfies the three most important properties of the cookie: (1) it uniquely identifies the state of client's data, (2) it can be used to synchronize with multiple servers, and (3) it can be used to detect that the server's data was reloaded. In addition, the cookie must contain enough information to allow the server to determine whether the cookie can be safely used with the search specification it is attached to. As discussed earlier in the document, the cookie can only be used with the search specification that is equally or more restrictive than the one for which the cookie was generated. Natkovich Proposed Standard - Expires: August 2000 9 An implementation must make sure that it can correctly update the client's cookie when there is a size limit imposed on the search results by either the client's request or by the server's configuration. If RUV is used as the cookie, entries last modified by a particular master must be sent to the client in the order of their last modified CSN. This ordering guarantees that the RUV can be updated after each entry is sent. An implementation must be able to notify the client about all entries deleted since the last implementation session. An LDUP compliant implementation can achieve this through the use of entry tombstones. The implementation should avoid aggressive tombstone purging since lack of tombstones would cause client's data to be reloaded. We suggest that only the tombstone content be removed during the regular trimming cycle while tombstones themselves are discarded much less frequently. The specification makes no guarantees about how soon a server should send notification of a changed entry to the client when the connection between the client and the server is kept open. This is intentional as any specific maximum delay would be impossible to meet in a distributed directory service implementation. Server implementors are encouraged to minimize the delay before sending notifications to ensure that clients' needs for timeliness of change notification are met. 9. Synchronizing Heterogeneous Data Stores Clients synchronizing multiple writeable data stores, like iPlanet Meta Directory, will only work correctly if each piece of information is single mastered (for instance, only by an LDUP compliant directory or only by Oracle). This is because different systems have different notions of time and different update resolution procedures. As a result, a change applied on one system can be discarded by the other, thus preventing the data stores from converging. 10. Security Considerations In some situations, it may be important to prevent general exposure of information about changes that occur in an LDAP server. Therefore, servers that implement the mechanism described in this document SHOULD provide a means to enforce access control on the entries returned and MAY also provide specific access control mechanisms to control the use of the controls and extended operations defined in this document. As with normal LDAP search requests, a malicious client can initiate a large number of persistent search requests in an attempt to consume all available server resources and deny service to legitimate clients. The protocol provides the means to stop malicious clients by disconnecting them from the server. The servers that implement the mechanism SHOULD provide the means to detect the Natkovich Proposed Standard - Expires: August 2000 10 malicious clients. In addition, the servers SHOULD provide the means to limit the number of resources that can be consumed by a single client. Access control on the data can be modified in such a way that the data is no longer visible to the client. The specification does not specify how the server should handle this condition. Moreover, data consistency is not guaranteed if access control is changed from a more restrictive to a less restrictive one. This is because access control can be considered as an additional filter on the search specification and the protocol does not support going from a more to a less restrictive search specification. See Client Side Considerations Section for more detailed explanation of the problem. 11. References [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [PSEARCH] M. Smith "A Simple LDAP Change Notification Mechanism", INTERNET-DRAFT , August 1998. [TSEARCH] M.Whal "LDAPv3 Triggered Search Control", INTERNET-DRAFT , August 1998. [DIRSYNC] M. Armijo "Microsoft LDAP Control for Directory Synchronization", INTERNET-DRAFT , August 1999. [LDUPARCH] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architecture", INTERNET-DRAFT , October 1999. [LDUPPROT] E. Stokes, G. Good "The LDUP Replication Update Protocol", INTERNET-DRAFT , October 1999. 12. Author's Addresses Olga Natkovich Netscape Communications Corp. 501. E. Middlefield Rd., Mailstop MV068 Mountain View, CA 94043 Phone: +1 650 937-4788 Email: olga@netscape.com Mark Smith Netscape Communications Corp. 501. E. Middlefield Rd., Mailstop MV068 Mountain View, CA 94043 Phone: +1 650 937-3477 Natkovich Proposed Standard - Expires: August 2000 11 Email: mcs@netscape.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Natkovich Proposed Standard - Expires: August 2000 12 --------------0A872BAA667F89A0A0481EFC-- From owner-ietf-ldup@imc.org Thu Mar 2 16:32:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28219 for ; Thu, 2 Mar 2000 16:32:29 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA00648 for ietf-ldup-bks; Thu, 2 Mar 2000 12:43:34 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00644 for ; Thu, 2 Mar 2000 12:43:32 -0800 (PST) Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Thu, 2 Mar 2000 13:15:51 -0600 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 14:15:38 -0500 Message-ID: <438D12915E64D2118AB10000F8C1C0780273419E@zcard00e.ca.nortel.com> From: "James Benedict" To: Linda Grimaldi , "Kurt D. Zeilenga" , ggood@netscape.com Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 14:15:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF847B.B0E352F8" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF847B.B0E352F8 Content-Type: text/plain; charset="ISO-8859-1" So lets try to get a list of all the current uses of changelogs (good or bad), and see if we can identify viable alternatives for them. If not, then I think we've got a good reason to look at changelog standardization. I'll start with my original list > Accountability (Who did what? When?) > Problem Tracking (Why is my email address X) > Recovery (Whoops, I didn't really want to rename everyone in > my directory) > Client-side caching (Give me all the changes to a subtree) and add, Change Monitoring (a new addition to the changelog means something changed somewhere... it's kind of a caching issue, but a little different) Anyone else? James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com] > Sent: Thursday, March 02, 2000 9:56 AM > To: Benedict, James [CAR:5N41-M:EXCH]; Kurt D. Zeilenga; > ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: RE: Changelog entries draft. Do not seem to find it. > > > Just one note on changelog standardization. I recently wrote > a program to monitor change logs for audit purposes. It > worked great on Innosoft- I had to re-write chunks of it for > Netscape. I was quite pissed off, and cursed both the IETF > and the LDAP working group for about a week (fortunately, to > no effect). Mr. Benedict makes a good point about using the > logs for other purposes. From a developer's perspective, I > would really appreciate some consistency here. > > Linda > > -----Original Message----- > From: James Benedict [SMTP:grunt@nortelnetworks.com] > Sent: Thursday, March 02, 2000 6:32 AM > To: Kurt D. Zeilenga; ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: RE: Changelog entries draft. Do not seem to find it. > > Changelogs seem to be falling between the cracks (LDAP, LDUP, > LCUP?). The concept of changelogs is important to > replication, but it also > has many other uses. > > Accountability (Who did what? When?) > Problem Tracking (Why is my email address X) > Recovery (Whoops, I didn't really want to rename everyone in > my directory) > Client-side caching (Give me all the changes to a subtree) > > If LDUP is going to subsume the role of maintaining changes > for replication > purposes, then I think it is important to make sure that > mechanisms are > in place to deal with these other uses as well. Otherwise, I think > changelogs should become part of the LDAP standard, not just > informational. > > It doesn't really matter how the directory server maintains this > information, but clients need to have a consistent way of > accessing it. > > James A Benedict > Advisor, IP Directory Systems Architecture > Preside Policy Services > NORTEL NETWORKS > Ph: (613) 763-3909 > > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Wednesday, March 01, 2000 1:30 PM > > To: ggood@netscape.com > > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > > ietf-ldup@imc.org > > Subject: Re: Changelog entries draft. Do not seem to find it. > > > > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > > >While I'm happy to resurrect the changelog draft and discuss > > publishing it as a standards-track document (informational, > > >probably), it's not going to be a part of the LDUP specification. > > > > I would support publication of the Changelog draft as an > > Informational RFC as it would document existing practices. > > The document would have to be amended, of course, to contain > > appropriate statements concerning IETF work in this area. > > > > Kurt > > > << File: ATT00002.htm >> > ------_=_NextPart_001_01BF847B.B0E352F8 Content-Type: text/html; charset="ISO-8859-1" RE: Changelog entries draft. Do not seem to find it.

So lets try to get a list of all the current uses of changelogs
(good or bad), and see if we can identify viable alternatives for them.
If not, then I think we've got a good reason to look at changelog standardization.

I'll start with my original list
> Accountability (Who did what? When?)
> Problem Tracking (Why is my email address X)
> Recovery (Whoops, I didn't really want to rename everyone in
> my directory)
> Client-side caching (Give me all the changes to a subtree)

and add,

Change Monitoring (a new addition to the changelog means something
changed somewhere... it's kind of a caching issue, but a little
different)

Anyone else?

James A Benedict
Advisor, IP Directory Systems Architecture
Preside Policy Services
NORTEL NETWORKS
Ph:  (613) 763-3909



> -----Original Message-----
> From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com]
> Sent: Thursday, March 02, 2000 9:56 AM
> To: Benedict, James [CAR:5N41-M:EXCH]; Kurt D. Zeilenga;
> ggood@netscape.com
> Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R;
> ietf-ldup@imc.org
> Subject: RE: Changelog entries draft. Do not seem to find it.
>
>
> Just one note on changelog standardization.  I recently wrote
> a program to monitor change logs for audit purposes.  It
> worked great on Innosoft- I had to re-write chunks of it for
> Netscape.  I was quite pissed off, and cursed both the IETF
> and the LDAP working group for about a week (fortunately, to
> no effect). Mr. Benedict makes a good point about using the
> logs for other purposes.  From a developer's perspective, I
> would really appreciate some consistency here.
>
> Linda
>
> -----Original Message-----
> From: James Benedict [SMTP:grunt@nortelnetworks.com]
> Sent: Thursday, March 02, 2000 6:32 AM
> To:   Kurt D. Zeilenga; ggood@netscape.com
> Cc:   Natarajan SK; ietf-ldapext@netscape.com; Savitha R;
> ietf-ldup@imc.org
> Subject:      RE: Changelog entries draft. Do not seem to find it.
>
> Changelogs seem to be falling between the cracks (LDAP, LDUP,
> LCUP?).  The concept of changelogs is important to
> replication, but it also
> has many other uses.
>
> Accountability (Who did what? When?)
> Problem Tracking (Why is my email address X)
> Recovery (Whoops, I didn't really want to rename everyone in
> my directory)
> Client-side caching (Give me all the changes to a subtree)
>
> If LDUP is going to subsume the role of maintaining changes
> for replication
> purposes, then I think it is important to make sure that
> mechanisms are
> in place to deal with these other uses as well.  Otherwise, I think
> changelogs should become part of the LDAP standard, not just
> informational.
>
> It doesn't really matter how the directory server maintains this
> information, but clients need to have a consistent way of
> accessing it.
>
> James A Benedict
> Advisor, IP Directory Systems Architecture
> Preside Policy Services
> NORTEL NETWORKS
> Ph:  (613) 763-3909
>
>
> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> > Sent: Wednesday, March 01, 2000 1:30 PM
> > To: ggood@netscape.com
> > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R;
> > ietf-ldup@imc.org
> > Subject: Re: Changelog entries draft. Do not seem to find it.
> >
> >
> > At 10:04 AM 3/1/00 -0800, Gordon Good wrote:
> > >While I'm happy to resurrect the changelog draft and discuss
> > publishing it as a standards-track document (informational,
> > >probably), it's not going to be a part of  the LDUP specification.
> >
> > I would support publication of the Changelog draft as an
> > Informational RFC as it would document existing practices.
> > The document would have to be amended, of course, to contain
> > appropriate statements concerning IETF work in this area.
> >
> > Kurt
> >
>  << File: ATT00002.htm >>
>

------_=_NextPart_001_01BF847B.B0E352F8-- From owner-ietf-ldup@imc.org Thu Mar 2 17:01:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29211 for ; Thu, 2 Mar 2000 17:01:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA01338 for ietf-ldup-bks; Thu, 2 Mar 2000 13:32:21 -0800 (PST) Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01334 for ; Thu, 2 Mar 2000 13:32:20 -0800 (PST) Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id VAA22898; Thu, 2 Mar 2000 21:30:07 GMT Received: from US-TR-EXCH-1.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id VAA27031 ; Thu, 2 Mar 2000 21:32:43 GMT Received: by us-tr-exch-1.tr.unisys.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 16:32:03 -0500 Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com, ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 16:32:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think the changelog draft should be standardized. It provides a simple, but useful feature. It's been implemented by more that one server and probably lots of clients. Perhaps it should include a disclaimer that it provides an interim solution until LDUP/LCUP mechanisms are defined and implemented. Accountability can be provided by adding createTimestamp and creatorsName to the changeLog entries. These are implied anyway, since change log records are defined as though they are entries in the directory, and all directory entries MAY contain these operational attributes. From owner-ietf-ldup@imc.org Thu Mar 2 17:24:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29771 for ; Thu, 2 Mar 2000 17:24:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA01593 for ietf-ldup-bks; Thu, 2 Mar 2000 13:54:46 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01589 for ; Thu, 2 Mar 2000 13:54:46 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA12512 for ; Thu, 2 Mar 2000 13:52:16 -0800 (PST) Received: from netscape.com ([208.12.63.184]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQTE6P00.CF2; Thu, 2 Mar 2000 13:54:25 -0800 Message-ID: <38BEE2B6.BE3DF1D2@netscape.com> Date: Thu, 02 Mar 2000 13:52:56 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com CC: ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Salter, Thomas A" wrote: > I think the changelog draft should be standardized. It provides a simple, > but useful feature. It's been implemented by more that one server and > probably lots of clients. > > Perhaps it should include a disclaimer that it provides an interim solution > until LDUP/LCUP mechanisms are defined and implemented. > > Accountability can be provided by adding createTimestamp and creatorsName to > the changeLog entries. These are implied anyway, since change log records > are defined as though they are entries in the directory, and all directory > entries MAY contain these operational attributes. I agree, with the caveat that supporting an LDAP-accessible changelog exactly as described in the internet draft may be very difficult in an environment featuring multi-master replication. As James Benedict mentioned, it would be very helpful to have an inventory of planned and existing applications that use changelogs. I've heard several mentioned on this mailing list - are there others? I have a strong suspicion that these applications will fall into one of a small number of classes, and that some of these classes may be better served by a newer client synchronization protocol that combines ideas from our Persistent Search draft, Innosoft's Triggered Search draft, and Microsoft's Dirsync draft. A first draft of that was posted to the ietf-lcup@netscape.com and ietf-ldup@imc.org mailing lists yesterday. -Gordon From owner-ietf-ldup@mail.imc.org Mon Mar 6 18:59:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01774 for ; Mon, 6 Mar 2000 18:59:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA09352 for ietf-ldup-bks; Mon, 6 Mar 2000 15:31:19 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA09347 for ; Mon, 6 Mar 2000 15:31:17 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 06 Mar 2000 16:31:18 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 06 Mar 2000 16:31:03 -0700 From: "Jim Sermersheim" To: Subject: LDUP management operations Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA09348 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I remember reading - though I can't find it now - something that essentially said we haven't yet defined the mechanisms that will be used to manage naming contexts, replicas, and update sessions. I think that much of the management that needs to happen can be done using existing ldap operations on the appropriate elements of the info model. I've listed all the management operations that we currently use with our directory and divided them into two groups - operations on elements of the info model, and update operations. Some people have suggested that all of these operations should be exposed as LDAP extended requests. I think that as long as it's not overly complex, the operations on the info model should be exposed as normal LDAP operations, while the update operations should be exposed as extended requests. What does everyone else think? Operations on the info model: · Add a new replica · Remove a replica · Change a replica's type · Join partition (delete naming context) · Split partition (add a naming context) · List partitions (list naming contexts) · Get partition entry count (get # of entries in a naming context) · Get partition info (various data about naming context) Update operations: · Send all updates · Receive all updates · Request partition sync · Request schema sync · Repair timestamps Jim From owner-ietf-ldup@mail.imc.org Mon Mar 6 19:00:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01841 for ; Mon, 6 Mar 2000 19:00:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA09451 for ietf-ldup-bks; Mon, 6 Mar 2000 15:38:56 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09447 for ; Mon, 6 Mar 2000 15:38:55 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA21773 for ; Mon, 6 Mar 2000 15:34:38 -0800 (PST) Received: from netscape.com ([208.12.63.253]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FR0XOY00.L5F; Mon, 6 Mar 2000 15:38:58 -0800 Message-ID: <38C44174.F04D2ABC@netscape.com> Date: Mon, 06 Mar 2000 15:38:28 -0800 From: merrells@netscape.com (John Merrells) Organization: Netscape Communications X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldup@imc.org Subject: Re: LDUP management operations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > > Some people have suggested that all of these operations should be exposed as LDAP extended requests. I think that as long as it's not overly complex, the operations on the info model should be exposed as normal LDAP operations, while the update operations should be exposed as extended requests. > > What does everyone else think? I strongly agree that they should be regular LDAP operations. John From owner-ietf-ldup@mail.imc.org Mon Mar 6 20:58:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24158 for ; Mon, 6 Mar 2000 20:58:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA11416 for ietf-ldup-bks; Mon, 6 Mar 2000 17:32:35 -0800 (PST) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA11412 for ; Mon, 6 Mar 2000 17:32:34 -0800 (PST) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id C9A1671F6; Mon, 6 Mar 2000 20:33:02 -0500 (EST) Message-ID: <38C45C76.80DCF00D@att.com> Date: Mon, 06 Mar 2000 20:33:42 -0500 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jim Sermersheim Cc: ietf-ldup@imc.org Subject: Re: LDUP management operations References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think that's a reasonable way to proceed. It minimizes complexity in verifying compliance if as much as possible is expressed as a profile of normal LDAP operations. Jim Sermersheim wrote: > > I remember reading - though I can't find it now - something that essentially said we haven't yet defined the mechanisms that will be used to manage naming contexts, replicas, and update sessions. I think that much of the management that needs to happen can be done using existing ldap operations on the appropriate elements of the info model. Its in the LDUP WG charter and is one of the missing deliverables: Am I to assume that you are offering to edit the deliverable on LDAPv3 Mandatory Replica Management? I believe Ed Reed and Mark Wahl were going to draft it, but have not seen any signs of it. Ed and Mark: any objections to Jim taking first shot at this? Perhaps the three of you can work together after his first draft? Chris. > > I've listed all the management operations that we currently use with our directory and divided them into two groups - operations on elements of the info model, and update operations. > > Some people have suggested that all of these operations should be exposed as LDAP extended requests. I think that as long as it's not overly complex, the operations on the info model should be exposed as normal LDAP operations, while the update operations should be exposed as extended requests. > > What does everyone else think? > > Operations on the info model: > · Add a new replica > · Remove a replica > · Change a replica's type > · Join partition (delete naming context) > · Split partition (add a naming context) > · List partitions (list naming contexts) > · Get partition entry count (get # of entries in a naming context) > · Get partition info (various data about naming context) > > Update operations: > · Send all updates > · Receive all updates > · Request partition sync > · Request schema sync > · Repair timestamps > > Jim -- ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup@mail.imc.org Mon Mar 6 21:34:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00007 for ; Mon, 6 Mar 2000 21:34:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA13578 for ietf-ldup-bks; Mon, 6 Mar 2000 18:13:14 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA13570 for ; Mon, 6 Mar 2000 18:13:12 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 06 Mar 2000 19:13:09 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 06 Mar 2000 19:12:53 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: LDUP management operations Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA13572 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit >>> Chris Apple 3/6/00 6:33:42 PM >>> >Am I to assume that you are offering to edit the deliverable on >LDAPv3 Mandatory Replica Management? I'll need to get my boss to help me find another vein before I can let any more blood. Barring that, sure. I'll know by next week. Jim From owner-ietf-ldup@mail.imc.org Thu Mar 9 17:29:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16039 for ; Thu, 9 Mar 2000 17:29:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09227 for ietf-ldup-bks; Thu, 9 Mar 2000 13:56:52 -0800 (PST) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09221 for ; Thu, 9 Mar 2000 13:56:46 -0800 (PST) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12TAvy-00083p-00 for ietf-ldup@imc.org; Thu, 9 Mar 2000 14:57:31 -0700 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Thu, 09 Mar 2000 14:48:57 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 09 Mar 2000 14:48:53 -0700 From: "Ed Reed" To: , , , , Cc: , Subject: LDAP subentry, discussion on CN {MUST or MAY} Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA09222 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Back in November and at the IETF meeting in Washington, we discussed whether LDAPsubentry should be STRUCTURAL or ABSTRACT in definition. Mark has pointed out that MAY would address Kurt's objection to MUST {cn}, but that leaves the many folks out there who define naming rules with a problem, when there are (possibly) no attributes defined on the class at all (cn is the only attribute declared for the ldapsubentry class definition). Frankly, those folks who DO define naming attributes and naming rules will have to deal in some way with other systems who don't, but that's a different discussion I think. I think the discussion in Washington concluded that we should 1) leave the class STRUCTURAL 2) leave MUST {cn} in the definition 3) encourage Kurt to derive a new subclass of LDAPsubentry for his special-purpose class, which defines the other attribute he will use to actually name his entries - meaning that yes, he will need to provide a (possibly useless, but not necessarily unique) value for the cn value Erik's argument, that to make it Auxiliary would require a proliferation of new structural types, each with their own new naming rules, is what finally persuaded me to avoid that approach. The consequences of blithly ignoring the operational experience of the X.500 community was also important. It will be easier, by far, for most people to treat LDAPsubentry as STRUCTURAL, and then to decorate it with additional attributes for their particular needs, than to require each new use to define a new STRUCTURAL class with it's own naming rules. As I think about it, though, there is one way to make both camps happy: 1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. 2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). Such an approach would violate the "fewer classes is better" rule. But I think it would satisfy both Kurt and the X.500 folks. This is the only issue standing in the way of a last call. Any final words? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM From owner-ietf-ldup@mail.imc.org Thu Mar 9 18:41:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07299 for ; Thu, 9 Mar 2000 18:41:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10709 for ietf-ldup-bks; Thu, 9 Mar 2000 15:18:51 -0800 (PST) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10705 for ; Thu, 9 Mar 2000 15:18:50 -0800 (PST) Received: from gypsy (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with SMTP id XAA03749; Thu, 9 Mar 2000 23:19:19 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <3.0.5.32.20000309151919.009539c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Mar 2000 15:19:19 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Cc: , , , , , , In-Reply-To: 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 02:48 PM 3/9/00 -0700, Ed Reed wrote: >1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. >2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). That's exactly what I had in mind all a long. But Mark's suggestion of a single STRUCTURAL class with MAY cn is works as well. I really don't understand the 'naming rule' issue with MUST vs. MAY. One additional comment: We need a STRUCTURAL object class for the Root DSE. This object class would have no naming attributes... and, in fact, doesn't need to MAY/MUST any attributes. Ie: ( NAME 'LDAPentry' SUP 'top' STRUCTURAL ) My question is, does it make sense to define subentry oc's in terms of LDAPentry? I would guess "no" as a entry and subentries are quite different. Anyways, food for thought. From owner-ietf-ldup@mail.imc.org Thu Mar 9 18:55:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11547 for ; Thu, 9 Mar 2000 18:55:56 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA10936 for ietf-ldup-bks; Thu, 9 Mar 2000 15:32:24 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA10932 for ; Thu, 9 Mar 2000 15:32:23 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Mar 2000 16:32:36 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 09 Mar 2000 16:29:48 -0700 From: "Sukanta Ganguly" To: , Cc: , , , , , , Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2871D584.D8B9BB83" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2871D584.D8B9BB83 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kurt, What is the reason behind the need to have a structural Object class for = RootDSE ? At the present the RootDSE is kinda defined. Newer attributes if = any are added to it on a a case by case basis and does go through the IEFT = WG check.=20 SG Novell Inc work 801-861-5190 >>> "Kurt D. Zeilenga" 03/09/00 04:20PM >>> At 02:48 PM 3/9/00 -0700, Ed Reed wrote: >1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with = no attributes defined at all. =20 >2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST = {cn} and normal naming rules for most foks to use they way I envision = they'll use it (by decorating them with AUXILIARY classes). That's exactly what I had in mind all a long. But Mark's suggestion of a single STRUCTURAL class with MAY cn is works as well. I really don't understand the 'naming rule' issue with MUST vs. MAY. One additional comment: We need a STRUCTURAL object class for the Root DSE. This object class would have no naming attributes... and, in fact, doesn't need to MAY/MUST any attributes. Ie: ( NAME 'LDAPentry' SUP 'top' STRUCTURAL ) My question is, does it make sense to define subentry oc's in terms of LDAPentry? I would guess "no" as a entry and subentries are quite different. Anyways, food for thought. --=_2871D584.D8B9BB83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kurt,
  What is the reason behind the need to have a structural Object = class=20 for RootDSE ? At the present the RootDSE is kinda defined. Newer attributes= if=20 any are added to it on a a case by case basis and does go through the IEFT = WG=20 check.
 
SG
Novell Inc
work 801-861-5190


>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 03/09/00=20 04:20PM >>>
At 02:48 PM 3/9/00 -0700, Ed Reed wrote:
>1)= =20 create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no=20 attributes defined at all. 
>2) create a STRUCTURAL class, = derived=20 from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks = to=20 use they way I envision they'll use it (by decorating them with = AUXILIARY=20 classes).

That's exactly what I had in mind all a long.  But = Mark's=20 suggestion
of a single STRUCTURAL class with MAY cn is works as = well.  I=20 really
don't understand the 'naming rule' issue with MUST vs. MAY.
One=20 additional comment:

We need a STRUCTURAL object class for the = Root=20 DSE.  This object
class would have no naming attributes... and, in = fact,=20 doesn't
need to MAY/MUST any attributes.  Ie:
   = (=20 <oid> NAME 'LDAPentry' SUP 'top' STRUCTURAL )

My question is, = does=20 it make sense to define subentry oc's
in terms of LDAPentry?  = I=20 would guess "no" as a entry and
subentries are quite different. &nb= sp;=20 Anyways, food for thought.

--=_2871D584.D8B9BB83-- From owner-ietf-ldup@mail.imc.org Thu Mar 9 19:01:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13104 for ; Thu, 9 Mar 2000 19:00:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA11031 for ietf-ldup-bks; Thu, 9 Mar 2000 15:37:47 -0800 (PST) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11027 for ; Thu, 9 Mar 2000 15:37:46 -0800 (PST) Received: from gypsy (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with SMTP id XAA03818; Thu, 9 Mar 2000 23:38:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <3.0.5.32.20000309153827.0095c1c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Mar 2000 15:38:27 -0800 To: "Sukanta Ganguly" From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Cc: "Ed Reed" , , , , , , , In-Reply-To: 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 04:29 PM 3/9/00 -0700, Sukanta Ganguly wrote: >What is the reason behind the need to have a structural >Object class for RootDSE ? The RootDSE, like any other entry, needs structure (per the X.500 model). Per previous discussions (see archives), a structural object class was going to be defined (by Mark Wahl) for LDAPv3 revised specifications. Kurt From owner-ietf-ldup@mail.imc.org Fri Mar 10 00:59:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05512 for ; Fri, 10 Mar 2000 00:59:34 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA24980 for ietf-ldup-bks; Thu, 9 Mar 2000 21:21:38 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA24975 for ; Thu, 9 Mar 2000 21:21:36 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Mar 2000 22:21:40 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 09 Mar 2000 22:21:32 -0700 From: "Jim Sermersheim" To: , , , , , Cc: , , "Mark Hinckley" Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA24977 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit To satisfy X.500, I believe that the LDAPSubentry object class can be STRUCTURAL and not include any attributes. From my reading, the attributes specified in the name form don't need to be made up of the attributes specified in the object class definition. The text I'm reading is in Section 12.6.2 of X.501: "The RDN attribute (or attributes) need not be chosen from the list of permitted attributes of the structural object class as specified in its structural or alias object class definition". I may be mis-reading that, but I don't think so. There also may be directory implementations that require naming attributes to be listed in the object class's MUST or MAY list (I know of at least one). Jim >>> "Ed Reed" 3/9/00 2:58:31 PM >>> Back in November and at the IETF meeting in Washington, we discussed whether LDAPsubentry should be STRUCTURAL or ABSTRACT in definition. Mark has pointed out that MAY would address Kurt's objection to MUST {cn}, but that leaves the many folks out there who define naming rules with a problem, when there are (possibly) no attributes defined on the class at all (cn is the only attribute declared for the ldapsubentry class definition). Frankly, those folks who DO define naming attributes and naming rules will have to deal in some way with other systems who don't, but that's a different discussion I think. I think the discussion in Washington concluded that we should 1) leave the class STRUCTURAL 2) leave MUST {cn} in the definition 3) encourage Kurt to derive a new subclass of LDAPsubentry for his special-purpose class, which defines the other attribute he will use to actually name his entries - meaning that yes, he will need to provide a (possibly useless, but not necessarily unique) value for the cn value Erik's argument, that to make it Auxiliary would require a proliferation of new structural types, each with their own new naming rules, is what finally persuaded me to avoid that approach. The consequences of blithly ignoring the operational experience of the X.500 community was also important. It will be easier, by far, for most people to treat LDAPsubentry as STRUCTURAL, and then to decorate it with additional attributes for their particular needs, than to require each new use to define a new STRUCTURAL class with it's own naming rules. As I think about it, though, there is one way to make both camps happy: 1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. 2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). Such an approach would violate the "fewer classes is better" rule. But I think it would satisfy both Kurt and the X.500 folks. This is the only issue standing in the way of a last call. Any final words? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM From owner-ietf-ldup@mail.imc.org Fri Mar 10 10:49:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26186 for ; Fri, 10 Mar 2000 10:49:09 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA21903 for ietf-ldup-bks; Fri, 10 Mar 2000 07:07:07 -0800 (PST) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21899 for ; Fri, 10 Mar 2000 07:07:05 -0800 (PST) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12TR1A-0008PT-00 for ietf-ldup@imc.org; Fri, 10 Mar 2000 08:07:56 -0700 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Fri, 10 Mar 2000 07:59:20 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 10 Mar 2000 07:59:01 -0700 From: "Ed Reed" To: Cc: , , , , , "Ed Reed" , Subject: draft-ietf-ldup-subentry-02.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4C15B0D8.51305C69" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_4C15B0D8.51305C69 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached internet draft, a product of the LDUP and = LDAPEXT (joint effort) working groups. It replaces draft-ietf-ldup-subentr= y-01.txt. The abstract is the same: This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class. To the working groups: I think this is ready for last call, now (joint, = as I recall). The only changes since the previous draft are to make cn an = optional, rather than mandatory, (MAY rather than MUST) attribute, remove = a gratuitous reference to the LDUP Information Model document, add the = LDAPEXT mailing list and adjust the author address for my new contact = information. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM --=_4C15B0D8.51305C69 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-02.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT=20 draft-ietf-ldup-subentry-02.txt=20 Ed Reed=20 Reed-Matthews, Inc.=20 March 9, 2000=20 =20 LDAP Subentry Schema=20 1. Status of this Memo=20 This document is an Internet-Draft and is in full=20 conformance with all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet=20 Engineering Task Force (IETF), its areas, and its working=20 groups. Note that other groups may also distribute working=20 documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by=20 other documents at any time. It is inappropriate to use=20 Internet-Drafts as reference material or to cite them other=20 than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt. =20 =20 The list of Internet-Draft Shadow Directories can be=20 accessed at http://www.ietf.org/shadow.html.=20 =20 This Internet-Draft expires on September 9, 2000.=20 2. Abstract=20 This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class.=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=20 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",=20 and "OPTIONAL" in this document are to be interpreted as=20 described in RFC 2119 [RFC2119]. The sections below=20 reiterate these definitions and include some additional=20 ones.=20 Reed [Page 1]=20 Expires September 9, 2000 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 3. Definition=20 3.1 ldapSubEntry Class=20 ( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry' =20 DESC 'LDAP Subentry class, version 1' =20 SUP top STRUCTURAL =20 MAY ( cn ) ) =20 The class ldapSubEntry is intended to be used as a super=20 class when defining other structural classes to be used as=20 LDAP Subentries. The presence of ldapSubEntry in the list=20 of super-classes of an entry in the directory makes that=20 entry an LDAP Subentry. Object classes derived from=20 ldapSubEntry are themselves considered ldapSubEntry=20 classes, for the purpose of this discussion.=20 LDAP Subentries MAY be named by their commonName attribute=20 [LDAPv3]. Other naming attributes are also permitted.=20 LDAP Subentries MAY be containers, unlike their [X.501]=20 counterparts.=20 LDAP Subentries MAY be contained by, and will usually be=20 located in the directory information tree immediately=20 subordinate to, administrative points and/or naming=20 contexts. Further (unlike X.500 subentries), LDAP=20 Subentries MAY be contained by other LDAP Subentries (the=20 way organizational units may be contained by other=20 organizational units). Deep nestings of LDAP Subentries=20 are discouraged, but not prohibited.=20 LDAP Subentries SHOULD be treated as "operational objects"=20 in much the same way that "operational attributes" are not=20 regularly provided in search results and read operations=20 when only user attributes are requested). =20 LDAP servers SHOULD implement the following special=20 handling of ldapSubEntry entries:=20 a) search operations which include a matching criteria=20 "objectclass=3DldapSubEntry" MUST include entries derived=20 from the ldapSubEntry class in the scope of their=20 operations; =20 b) search operations which do not include a matching=20 criteria "objectclass=3DldapSubEntry" MUST IGNORE entries=20 Reed [Page 2]=20 Expires September 9, 2000=20 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 derived from the ldapSubEntry class, and exclude them from=20 the scope of their operations.=20 The combination of SHOULD and MUST in the special handling=20 instructions, above, are meant to convey this: Servers=20 SHOULD support this special handling, and if they do they=20 MUST do it as described, and not some other way.=20 4. Security Considerations=20 LDAP Subentries will frequently be used to hold data which=20 reflects either the actual or intended behavior of the=20 directory service. As such, permission to read such=20 entries MAY need to be restricted to authorized users. =20 More importantly, IF a directory service treats the=20 information in an LDAP Subentry as the authoritative source=20 of policy to be used to control the behavior of the=20 directory, then permission to create, modify, or delete=20 such entries MUST be carefully restricted to authorized=20 administrators.=20 5. References=20 [LDAPv3] S. Kille, M. Wahl, and T. Howes, "Lightweight=20 Directory Access Protocol (v3)", RFC 2251, December 1997=20 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993=20 6. Copyright Notice=20 Copyright (C) The Internet Society (1999). All Rights=20 Reserved. =20 =20 This document and translations of it may be copied and=20 furnished to others, and derivative works that comment on=20 or otherwise explain it or assist in its implementation may=20 be prepared, copied, published and distributed, in whole or=20 in part, without restriction of any kind, provided that the=20 above copyright notice and this paragraph are included on=20 all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by=20 removing the copyright notice or references to the Internet=20 Reed [Page 3]=20 Expires September 9, 2000=20 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 Society or other Internet organizations, except as needed=20 for the purpose of developing Internet standards in which=20 case the procedures for copyrights defined in the Internet=20 Standards process must be followed, or as required to=20 translate it into languages other than English.=20 =20 The limited permissions granted above are perpetual and=20 will not be revoked by the Internet Society or its=20 successors or assigns.=20 =20 This document and the information contained herein is=20 provided on an "AS IS" basis and THE INTERNET SOCIETY AND=20 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL=20 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED=20 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL=20 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 7. Acknowledgements=20 The use of subEntry object class to store Replica and=20 Replication Agreement information is due primarily to the=20 lucid explanation by Mark Wahl, Innosoft, of how they could=20 be used and extended.=20 =20 The IETF takes no position regarding the validity or scope=20 of any intellectual property or other rights that might be=20 claimed to pertain to the implementation or use of the=20 technology described in this document or the extent to=20 which any license under such rights might or might not be=20 available; neither does it represent that it has made any=20 effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track=20 and standards-related documentation can be found in BCP-11.=20 Copies of claims of rights made available for publication=20 and any assurances of licenses to be made available, or the=20 result of an attempt made to obtain a general license or=20 permission for the use of such proprietary rights by=20 implementors or users of this specification can be obtained=20 from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its=20 attention any copyrights, patents or patent applications,=20 or other proprietary rights which may cover technology that=20 may be required to practice this standard. Please address=20 the information to the IETF Executive Director.=20 Reed [Page 4]=20 Expires September 9, 2000=20 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 8. Author's Address=20 Edwards E. Reed=20 Reed-Matthews, Inc.=20 1064 E 140 North=20 Lindon, UT 84042=20 USA=20 E-mail: eer@oncalldba.com =20 =20 LDUP Mailing List: ietf-ldup@imc.org =20 LDAPEXT Mailing List: ietf-ldapext@netscape.com=20 Reed [Page 5]=20 Expires September 9, 2000=20 =0C --=_4C15B0D8.51305C69-- From owner-ietf-ldup@mail.imc.org Fri Mar 10 14:20:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10563 for ; Fri, 10 Mar 2000 14:20:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25407 for ietf-ldup-bks; Fri, 10 Mar 2000 10:51:01 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25401 for ; Fri, 10 Mar 2000 10:50:29 -0800 (PST) Received: from qsun.mt.att.com ([135.16.30.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with SMTP id NAA01405 for ; Fri, 10 Mar 2000 13:50:45 -0500 (EST) Received: from schooner.local.windrose.omaha.ne.us by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id NAA09676; Fri, 10 Mar 2000 13:50:22 -0500 From: "Ryan Moats" To: , Cc: "Richard V Huber" Subject: Second proposed mail on LCUP draft... Date: Fri, 10 Mar 2000 12:49:29 -0600 Message-ID: <001601bf8ac1$5db18720$e3c8090a@schooner.local.windrose.omaha.ne.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <200003101721.MAA01561@qsun.mt.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Having read the LCUP draft, we're concerned that this doesn't seem to address the issues that were identified with either the old or new Persistent and Triggered searches drafts. A noticeable point is that the definition doesn't distinguish (at the protocol message level) between the cases where a server shuts down a connection normally and where it shuts down a connection because of resource exhaustion. Further, the draft needs to provide some guidance/mandate on client behavior in the second case. Without it, what's to stop a client from reconnecting and resubmitting the control (and how does that help resource exhaustion)? The LCUP draft might want to contain something along the lines of the "Implementation Considerations" section of the new psearch draft. The intended use discussion raises some interesting scale issues that LCUP should address. LCUP draft should mention whether any other LDAP requests/responses can be sent via the open connection while a keepConnection request is active (The draft doesn't seem to say. We hope the answer is "none apart from the usual suspects like ABANDON"). Why MUST a stateUpdate message contain a valid entry? If the client sends the server a bad cookie, the server sends back unwillingToPerform. Is there some problem in generating a more specific error? Using a really general error seems like it might lead to a lot of customer service support time to track down the real problem. Why SHOULD size and time limits be ignored for persistent operations? Why not MUST? The Security Considerations address the issue of limiting resources that are accessed by a single client, but don't seem to address the same issues if the "attacker" just uses several clients. Ryan Moats Rick Huber From owner-ietf-ldup@mail.imc.org Fri Mar 10 14:45:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19281 for ; Fri, 10 Mar 2000 14:45:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25659 for ietf-ldup-bks; Fri, 10 Mar 2000 11:12:58 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25655 for ; Fri, 10 Mar 2000 11:12:56 -0800 (PST) Received: from qsun.mt.att.com ([135.16.12.1]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with SMTP id OAA10364 for ; Fri, 10 Mar 2000 14:13:18 -0500 (EST) Received: from schooner.local.windrose.omaha.ne.us by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id OAA12494; Fri, 10 Mar 2000 14:13:02 -0500 From: "Ryan Moats" To: , Cc: "Richard V Huber" Subject: Oops: comments on LCUP draft Date: Fri, 10 Mar 2000 13:12:08 -0600 Message-ID: <001e01bf8ac4$87aabd00$e3c8090a@schooner.local.windrose.omaha.ne.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <200003101721.MAA01561@qsun.mt.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit (That's what I get for not paying attention to subject lines. This is a resend with a correct subject. Sigh) Having read the LCUP draft, we're concerned that this doesn't seem to address the issues that were identified with either the old or new Persistent and Triggered searches drafts. A noticeable point is that the definition doesn't distinguish (at the protocol message level) between the cases where a server shuts down a connection normally and where it shuts down a connection because of resource exhaustion. Further, the draft needs to provide some guidance/mandate on client behavior in the second case. Without it, what's to stop a client from reconnecting and resubmitting the control (and how does that help resource exhaustion)? The LCUP draft might want to contain something along the lines of the "Implementation Considerations" section of the new psearch draft. The intended use discussion raises some interesting scale issues that LCUP should address. LCUP draft should mention whether any other LDAP requests/responses can be sent via the open connection while a keepConnection request is active (The draft doesn't seem to say. We hope the answer is "none apart from the usual suspects like ABANDON"). Why MUST a stateUpdate message contain a valid entry? If the client sends the server a bad cookie, the server sends back unwillingToPerform. Is there some problem in generating a more specific error? Using a really general error seems like it might lead to a lot of customer service support time to track down the real problem. Why SHOULD size and time limits be ignored for persistent operations? Why not MUST? The Security Considerations address the issue of limiting resources that are accessed by a single client, but don't seem to address the same issues if the "attacker" just uses several clients. Ryan Moats Rick Huber From owner-ietf-ldup@mail.imc.org Fri Mar 10 18:21:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04695 for ; Fri, 10 Mar 2000 18:20:59 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA27986 for ietf-ldup-bks; Fri, 10 Mar 2000 14:09:13 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27981 for ; Fri, 10 Mar 2000 14:09:12 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA12487 for ; Fri, 10 Mar 2000 14:07:17 -0800 (PST) Received: from netscape.com ([208.12.63.184]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FR888000.9LK for ; Fri, 10 Mar 2000 14:09:36 -0800 Message-ID: <38C97244.3AF4AFBB@netscape.com> Date: Fri, 10 Mar 2000 14:08:05 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: [Fwd: draft-ietf-ldup-framing-00.txt] Content-Type: multipart/mixed; boundary="------------FAB4166797666386D38E0ADB" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FAB4166797666386D38E0ADB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit LDUP people: here's the LDUP Framing draft. If you'll recall, at the most recent IETF we agreed to produce a draft describing a set of basic begin/end framing extended operations. These then would be used both by the LDUP protocol as well as the LBURP bulk update protocol. I'll also forward the LDUP protocol document, which has been revised to use the extended requests and responses defined here. -Gordon --------------FAB4166797666386D38E0ADB Content-Type: message/rfc822 Content-Disposition: inline Message-ID: <38C9485C.A28E93FB@netscape.com> Date: Fri, 10 Mar 2000 11:09:16 -0800 From: Gordon Good X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: Gordon Good Subject: draft-ietf-ldup-framing-00.txt Content-Type: multipart/mixed; boundary="------------649497866FBD2C31566FA7D3" This is a multi-part message in MIME format. --------------649497866FBD2C31566FA7D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Editor, Please publish the attached draft. It is a new draft, and a product of the IETF LDUP Working Group. Thank you. --------------649497866FBD2C31566FA7D3 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ldup-framing-00.txt" Content-Disposition: inline; filename="draft-ietf-ldup-framing-00.txt" Content-Transfer-Encoding: 7bit Extended Operations for Framing LDAP Operations Internet-Draft Intended Category: Standards Track Expires: September 10, 2000 Ellen Stokes IBM Corporation Roger Harrison Novell, Inc. Gordon Good Netscape Communications Corp. March 10, 2000 Extended Operations for Framing LDAP Operations Filename: draft-ietf-ldup-framing-00.txt Table of Contents 1. Status of this Memo.............................................2 2. Abstract........................................................2 3. Overview........................................................2 4. Protocol element definitions....................................3 4.1 StartFramedProtocolRequest Extended Operation...................3 4.2 StartFramedProtocolResponse Extended Operation..................3 4.3 EndFramedProtocolRequest Extended Operation.....................4 4.4 EndFramedProtocolResponse Extended Operation....................4 5. Acknowledgments.................................................5 6. References......................................................5 7. Author's Addresses..............................................5 Stokes, Harrison and Good [Page 1] Internet-Draft LDUP Workgroup March 10, 2000 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet Draft expires September 10, 2000. 2. Abstract Certain types of LDAP applications can benefit from the ability to specify the beginning and end of a related group of operations. For example, the LDUP multimaster update protocol [ARCHITECTURE] requires that two servers agree to begin a session to transfer pending replication updates. This document provides a framework for constructing protocols that feature a framed set of related operations. It defines a pair of LDAPv3 extended operations that provide begin-end framing, and a pair of extended operations used to respond the begin-end framing operations. The nature of the actual LDAP operations carried inside these framing operations is not specified in this document. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. Certain terms used in this document are defined in the document "LDAP Replication Architecture" [ARCHITECTURE]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 3. Overview This document describes two LDAPv3 Extended Operations that are used to signal the beginning and end of a set of grouped operations, and Stokes, Harrison and Good [Page 2] Internet-Draft LDUP Workgroup March 10, 2000 two LDAPv3 extended operations that are used to respond to these operations. These extended operations provide a framework that may be used when developing a protocol that requires begin-end framing. 4. Protocol element definitions 4.1 StartFramedProtocolRequest Extended Operation The StartFramedProtocolRequest extended operation indicates that the initiator wishes to begin transmission of a set of related LDAP operations. The requestValue of the StartFramedProtocolRequest extended operation contains an OID that describes the specific framed protocol being initiated, and a protocol-specific payload. An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName portion of the StartFramedProtocolRequest must be the OID "2.16.840.1.113719.1.142.100.1". The requestValue of the StartFramedProtocolRequest must be set to the BER-encoding of the following: StartFramedProtocolRequestValue ::= SEQUENCE { framedProtocolOID LDAPOID, framedProtocolPayload OPTIONAL OCTET STRING } The parameters in the requestValue of the StartFramedProtocolRequest are: - framedProtocolOID: An OID that uniquely identifies the protocol framed by this operation. - framedProtocolPayload: An octet string that contains protocol-specific information. 4.2 StartFramedProtocolResponse Extended Operation The StartFramedProtocolResponse extended operation is sent in response to a StartFramedProtocolResponse extended operation. An LDAPv3 Extended Response is defined in [LDAPv3] as follows: Stokes, Harrison and Good [Page 3] Internet-Draft LDUP Workgroup March 10, 2000 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the StartFramedProtocolResponse must be the OID "2.16.840.1.113719.1.142.100.2". The response of the StartFramedProtocolResponse is set to the BER- encoding of a protocol-specific response. 4.3 EndFramedProtocolRequest Extended Operation The EndFramedProtocolRequest extended operation indicates the end a set of related LDAP operations. The requestValue of the EndFramedProtocolRequest extended operation contains a protocol- specific payload. An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName of the EndFramedProtocolRequest must be the OID "2.16.840.1.113719.1.142.100.4". The requestValue of the EndFramedProtocolRequest is set to the BER- encoding of a protocol-specific response. 4.4 EndFramedProtocolResponse Extended Operation The EndFramedProtocolResponse extended operation is sent in response to an EndFramedProtocolRequest. An LDAPv3 Extended Response is defined in [LDAPv3] as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the EndFramedProtocolResponse must be the OID "2.16.840.1.113719.1.142.100.5". Stokes, Harrison and Good [Page 4] Internet-Draft LDUP Workgroup March 10, 2000 The response of the EndFramedProtocolResponse is set to the BER- encoding of a protocol-specific response. 5. Acknowledgments The authors gratefully acknowledge the contributions of the IETF LDUP working group. 6. References [KEYWORDS] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- els", Harvard University, RFC 2119, March 1997. [ARCHITECTURE] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec- ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999. [LDAPv3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. 7. Author's Addresses Ellen Stokes IBM 11400 Burnet Rd Austin, TX 78758 USA EMail: stokes@austin.ibm.com phone: +1 512 838 3725 fax: +1 512 838 0156 Roger Harrison Novell, Inc. 122 E. 1700 S. Provo, UT 84606 USA EMail: roger_harrison@novell.com Phone: +1 801 861 2642 Gordon Good Netscape Communications Corp. 501 E. Middlefield Rd. Mailstop MV068 Stokes, Harrison and Good [Page 5] Internet-Draft LDUP Workgroup March 10, 2000 Mountain View, CA 94043 USA EMail: ggood@netscape.com Phone: +1 650 937-3825 Appendix A - Complete ASN.1 Definition StartFramedProtocolRequest ::= ExtendedRequest StartFramedProtocolRequestValue ::= SEQUENCE { framedProtocolOID LDAPOID, framedProtocolPayload OPTIONAL OCTET STRING } StartFramedProtocolResponse ::= ExtendedResponse EndFramedProtocolRequest ::= ExtendedRequest EndFramedProtocolResponse ::= ExtendedResponse Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Stan- dards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- NESS FOR A PARTICULAR PURPOSE. Stokes, Harrison and Good [Page 6] --------------649497866FBD2C31566FA7D3-- --------------FAB4166797666386D38E0ADB-- From owner-ietf-ldup@mail.imc.org Fri Mar 10 18:41:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12081 for ; Fri, 10 Mar 2000 18:41:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA27904 for ietf-ldup-bks; Fri, 10 Mar 2000 14:02:21 -0800 (PST) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27900 for ; Fri, 10 Mar 2000 14:02:20 -0800 (PST) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12TXV3-0007AT-00 for ietf-ldup@imc.org; Fri, 10 Mar 2000 15:03:13 -0700 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Fri, 10 Mar 2000 14:54:39 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 10 Mar 2000 14:54:13 -0700 From: "Ed Reed" To: Cc: , "Ed Reed" Subject: draft-ietf-ldup-infomod-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA27901 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Please publish the attached internet draft. It replaces draft-ietf-ldup-infomod-00.txt, but you havent' gotten all the interrum versions. It is the product of the LDUP working group. Abstract: This interrum version of the LDUP Information Model is intended to provide the developer community with updates to the design, and a snapshot of the work in progress. Work is currently underway to ensure that this document is fully alligned with the LDUP Architectural Model document. [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM From owner-ietf-ldup@mail.imc.org Fri Mar 10 18:46:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13635 for ; Fri, 10 Mar 2000 18:46:06 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA27914 for ietf-ldup-bks; Fri, 10 Mar 2000 14:03:32 -0800 (PST) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27910 for ; Fri, 10 Mar 2000 14:03:30 -0800 (PST) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12TXW2-0007As-00 for ietf-ldup@imc.org; Fri, 10 Mar 2000 15:04:15 -0700 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Fri, 10 Mar 2000 14:55:41 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 10 Mar 2000 14:55:18 -0700 From: "Ed Reed" To: Cc: , "Ed Reed" Subject: draft-ietf-ldup-infomod-03.txt - with the attachment, this time Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_BBE2474D.95F498AD" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_BBE2474D.95F498AD Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached internet draft. It replaces draft-ietf-ldup-in= fomod-00.txt, but you havent' gotten all the interrum versions. It is the = product of the LDUP working group. Abstract: This interrum version of the LDUP Information Model is intended to provide = the developer community with updates to the design, and a snapshot of the = work in progress. Work is currently underway to ensure that this document = is fully alligned with the LDUP Architectural Model document. [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM --=_BBE2474D.95F498AD Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-infomod-03.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT=20 draft-ietf-ldup-infomod-03.txt=20 Ed Reed=20 Reed-Matthews, Inc.=20 March 9, 2000=20 =20 LDUP Replication Information Model=20 1. Status of this Memo=20 This document is an Internet-Draft and is in full conformance with all=20 provisions of Section 10 of RFC2026.=20 Internet-Drafts are working documents of the Internet Engineering Task=20 Force (IETF), its areas, and its working groups. Note that other=20 groups may also distribute working documents as Internet-Drafts. =20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress." =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt. =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 This Internet-Draft expires on May 11, 1999.=20 2. Abstract=20 [LDUP Model] describes the architectural approach to replication of=20 LDAP directory contents. This document describes the information=20 model and schema elements which support LDAP Replication Services=20 which conform to [LDUP Model].=20 Directory schema is extended to provide object classes, subentries,=20 and attributes to describe areas of the namespace which are under=20 common administrative authority, units of replication (ie, subtrees,=20 or partitions of the namespace, which are replicated), servers which=20 hold replicas of various types for the various partitions of the=20 namespace, which namespaces are held on given servers, and the=20 progress of various namespace management and replication operations. =20 Among other things, this knowledge of where directory content is=20 Reed [Page 1]=20 Expires September 9, 2000 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 located will provide the basis for dynamic generation of LDAP=20 referrals for clients who can follow them.=20 The controlling framework by which the relationships, types, and=20 health of replicas of the directory content will be defined so that,=20 as much as possible, directory content is itself used to monitor and=20 control the environment.=20 Security information, including access control policy identifiers and=20 information will be treated as directory content by the replication=20 protocols when specified by the LDAPEXT group. =20 The information model will describe required and optional house- keeping duties for compliant systems to implement, such as garbage=20 collection of deleted objects, reconciliation of moved and renamed=20 objects, update sequencing and transaction bracketing of changes, etc.=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC 2119 [RFC2119]. The=20 sections below reiterate these definitions and include some additional=20 ones.=20 2.1 Changes in this version=20 LDAP Subentry definition is moved to its own document [SUBENTRY].=20 LDAP Schedule Subentry definition is defined.=20 LDAP Access Point removed in favor of just using the DN of the server=20 holding the replica (so a new syntax isn't required).=20 LDAP Change Sequence Number syntax eleminated in favor of just calling=20 it a CaseIgnoreString, so new comparison rules aren't required.=20 Deleted ldapSearchFilter definition from here. Sparse replicas is=20 deferred. Might sparse be supported for single-master configurations=20 (read-only, of course). =20 Fractional are okay in multi-master configurations, but again, only on=20 read-only replicas.=20 Changed the naming convention upper-lower case usage to look less=20 weird.=20 Note:=20 Reed [Page 2]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 Consistency discussion=20 Schema document must clearly indicate that clients can and should=20 inspect the replica subentries to understand the single-master/multi- master nature of the naming context to which they're talking.=20 The paradigm change, to distributed data, needs to be exhaustively=20 discussed in the profile documents. How old applications which assume=20 single-master behave or misbehave in a multi-master environment is=20 critical to make clear. Draw examples from SMP pre-emptive=20 programming practices, from DNS vs host file models, etc.=20 Decisions from wash ietf_=20 1) define two simple schema classes _ event driven histeresis=20 buckets, and cron-like thing. Then, the replica has a single=20 value pointer to a schedule. More schedule things can be=20 defined in the future.=20 2) Create attribute ReplicaURI to provide service access point for=20 that replica. No DSA entry requirement.=20 3) Replica id table discussion should move to protocol spec.=20 To do:=20 1) define the cron schedule subentry class=20 2) define the rest of the attributes used in the classes=20 3) verify LDUP OID number with Novell (!) one more time=20 4) verify all OIDs assigned=20 5) verify all OIDs documented at the end of the document=20 6) scrub editorial comments=20 7) cross reference with arch document on schema element names=20 Reed [Page 3]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 Table of Contents=20 1. Status of this Memo .............................................1=20 2. Abstract =0D 1=20 2.1 Changes in this version........................................2=20 3. Introduction ....................................................4=20 3.1 Scope 4=20 3.2 Terms and Definitions..........................................5=20 4. Data design: ....................................................5=20 5. Directory Knowledge .............................................5=20 6. Schema 6=20 6.1 Data Structure Definitions.....................................6=20 6.1.1 ldapChangeSequenceNumber..................................6=20 6.2 Attribute Definitions..........................................7=20 6.2.1 attributeExclusionFilter..................................7=20 6.2.2 attributeInclusionFilter..................................8=20 6.2.3 replicaURI................................................8=20 6.2.4 replicationStatus.........................................9=20 6.2.5 replicaType...............................................9=20 6.2.6 SecsToWait Attributes....................................11=20 6.2.6.1 secsToWaitCat1 ........................................11=20 6.2.6.2 secsToWaitCat2 ........................................11=20 6.2.6.3 secsToWaitCat3 ........................................11=20 6.2.6.4 secsToWaitCat4 ........................................11=20 6.2.6.5 secsToWaitCat5 ........................................11=20 6.2.7 updateVector.............................................12=20 6.3 Class Definitions.............................................12=20 6.3.1 nameContext..............................................12=20 6.3.2 replicaSubentry..........................................12=20 6.3.3 replicaAgreementSubentry.................................13=20 6.3.4 eventScheduledSubentry Class.............................14=20 6.3.5 timeScheduledSubentry Class..............................15=20 7. Object Identifier Assignments ..................................15=20 8. Security Considerations ........................................16=20 9. References .....................................................16=20 10. =0D Copyright Notice .......................................= ........17=20 11. =0D Acknowledgements .......................................= ........17=20 12. =0D Author's Address .......................................= ........18=20 3. Introduction=20 3.1 Scope=20 This document describes schema of subentries representing replicas,=20 replication agreements and their dependencies.=20 Reed [Page 4]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 Management and status schema elements may be defined if there is=20 sufficient consensus.=20 Semantic interpretation of schema elements, including any special=20 handling expectations are to be provided here.=20 3.2 Terms and Definitions=20 Definitions are provided in [LDUP Requirements], and may be reproduced=20 here for the convenience of the reader.=20 4. Data design: =20 As described in [LDUP Model], knowledge of replicated portions of the=20 directory information tree (DIT) is stored in the directory itself. =20 An auxiliary class is defined to designate containers, or nodes, in=20 the DIT which are the root-most, or base, of naming contexts=20 [RFC2251]. Directory subentries [X501] are used to hold information=20 about replicas and replica agreements. =20 5. Directory Knowledge=20 Information about what replicas exist, what they contain, their types,=20 where they are stored, and how they may be contacted inevitably=20 provides the basis for distributed directory knowledge. As namespaces=20 from stand-alone servers are inter-connected with one another, this=20 replica information can and will be used by name resolution operations=20 to locate servers holding copies of specific objects, and to optimize=20 distributed searches which span multiple Naming Contexts.=20 However, the focus of this document is NOT to fully enable such=20 distributed directory uses. Instead, we are focused on how portions=20 of the namespace (Directory Information Tree - DIT) may be replicated,=20 and how those replicas are configured and related to one another via=20 Replication Agreements.=20 As such, the following high level description (from [LDUP Model])of=20 the information model envisioned is provided as reference for the=20 reader before presenting the detailed specifications.=20 Generally, the DSE Naming Context attribute of an LDAPv3 server names=20 the Naming Contexts for which there are replicas on that server.=20 Reed [Page 5]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 The Naming Context Auxiliary Class (nameContext) is added to container=20 objects which may have separately defined replication policy.=20 Immediately subordinate to a Naming Context object are the Replica=20 Subentry containers which identify where the identified replica=20 resides (ie, its LDAP Access Point), its type (Primary, Updateable,=20 ReadOnly), if it is sparse, the LDAP search filter which defines what=20 object classes it holds, and if it is fractional, the attributes it=20 does or does not hold.=20 Immediately subordinate in the namespace to a Replica Subentry are=20 Replication Agreement leaf entries which each identify another=20 Replica, the scheduling policy for replication operations (including=20 times when replication is to be performed, when it is not to be=20 performed, or the policies governing event-driven replication=20 initiation).=20 6. Schema=20 6.1 Data Structure Definitions=20 For the purposes of defining the encoding rules for attribute=20 structures, the BNF definitions in section 4.1 of [RFC2252] will be=20 used. They are based on the BNF styles of [RFC822].=20 To avoid requiring new syntax support to be added unnecessarily to=20 existing LDAPv3 directory service implementations (and the=20 accompanying matching rules, etc. they would entail), a string=20 encoding is defined for ldapChangeSequenceNumber which can use=20 CaseIgnoreString matching rules for ordering and equality.=20 6.1.1 ldapChangeSequenceNumber=20 ( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Change Sequence Number' )=20 Values in this syntax are encoded according to the following BNF. =20 Note there MUST NOT be any whitespace separators, unless they are in=20 replicaID, which must be encoded according to the instructions below.=20 This encoding is specified so that the CaseIgnoreString equality and=20 ordering rules will work correctly when replicaNumber is used.=20 When replicaID is used, CaseIgnoreString comparison rules will not=20 work unless each replicaID is exactly the same length with no padded=20 Reed [Page 6]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 white spaces (because CaseIgnoreString suppresses duplicate adjacent=20 white space when it compares two strings).=20 LDAPChangeSequenceNumber =3D GeneralizedZTime "#" S1 "#" replicaID=20 "#" S2 =20 GeneralizedZTime =3D yyyy | mm | dd | hh | mi | ss | "Z"=20 yyyy =3D dddd =20 mm =3D dd =20 dd =3D dd =20 hh =3D dd =20 mi =3D dd =20 ss =3D dd =20 replicaID =3D dstring =20 S1, S2 =3D numericstring=20 The GeneralizedTime is used as described (cf. [X680] section 39.3 case=20 b) without separators or whitespace, and representing a coordinated=20 universal time (i.e., Greenwich Mean Time, or GMT). All times=20 referenced by this syntax MUST be normalized to GMT - no local times,=20 nor time zone offsets are permitted. To simplify comparisons of two=20 CSNs, the "Z" MUST be the UTF-8 capital-Z character.=20 The ReplicaID represents the specific Replica of this Naming Context=20 where the event associated with this LDAPChangeSequenceNumber=20 occurred. Note that in actual transfer, the ReplicaID MAY be=20 represented by a number (see the specification of the=20 replicaLookupTable, above). =20 S1 and S2 are sequence numbers which are used to order two events with=20 the same Generalized Time and ReplicaID. In order to use string=20 matching rules for equality and ordering with values with this=20 encoding, the length of each field must be consistent. Thus, all=20 instances of S1 MUST be represented with the same number of digits,=20 using leading zeros as necessary. The same with S2 and replicaID. =20 6.2 Attribute Definitions=20 6.2.1 attributeExclusionFilter=20 ( 2.16.840.1.113719.142.4.1 NAME 'attributeExclusionFilter'=20 SYNTAX OCTET STRING=20 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )=20 Reed [Page 7]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 The attributeExclusionFilter is intended to contain a list of=20 attributes in the form of an AttributeDescriptionList as described in=20 section 4.5.1. Search Request of [RFC2251] with the following=20 interpretation: an empty attributeExclusionFilter means that no=20 attributes are excluded; the special values "*" and "1.1" mean that=20 ALL attributes are excluded. =20 A non-empty attributeExclusionFilter attribute on a replica subEntry=20 describes the attributes NOT PRESENT on entries held by that replica. =20 Replicas MUST NOT accept changes for attributes they're not permitted=20 to hold, per the attributeInclusionFilter and attributeExclusionFilter=20 attributes on their replica subEntry.=20 A non-empty attributeExclusionFilter attribute on a=20 replicationAgreement subEntry describes which additional attributes=20 are to be excluded from the updates to be sent from the supplier=20 replica to the consumer replica. =20 6.2.2 attributeInclusionFilter=20 ( {2.16.840.1.113719.142.4.2 NAME 'attributeInclusionFilter'=20 SYNTAX OCTET STRING=20 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )=20 The attributeInclusionFilter is intended to contain a list of=20 attributes in the form of an AttributeDescriptionList as described in=20 section 4.5.1. Search Request of [RFC2251] with the following=20 interpretation: an empty attributeInclusionFilter means that all=20 attributes are included; the special value "*" means that ALL=20 attributes are included; the special value "1.1" is meaningless and is=20 ignored in this usage.=20 A non-empty attributeInclusionFilter attribute on a replica subEntry=20 describes the attributes that may be PRESENT on entries held by that=20 replica. Replicas MUST NOT accept changes for attributes they're not=20 permitted to hold, per the attributeIncludionFilter and=20 attributeExclusionFilter attributes on their replica subEntry.=20 6.2.3 replicaURI=20 (2.16.840.1.113719.142.4.x NAME `replicaURI'=20 DESC `how to connect to this replica'=20 SYNTAX ldapURI=20 USAGE dSAOperation )=20 Reed [Page 8]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 6.2.4 replicationStatus=20 (2.16.840.1.113719.142.4.3 NAME 'replicationStatus'=20 DESC 'human readable status of last replication attempt'=20 SYNTAX DirectoryString=20 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )=20 The replicationStatus attribute MAY be used to hold a human readable=20 message describing the most recent replication session attempt for a=20 replicationAgreement.=20 For example, such a messages might include =20 1) 19980805162203Z # Success #=20 2) 19980805162322Z # Failure # Server too busy, try again=20 3) 19980805170215Z # Failure # Unable to connect to DSA=20 4) 19980806002301Z # Failure # Authentication failed=20 5) 19980806003201Z # Failure # lost connection, reset by peer=20 It is suggested, but not required, that the time of a replication=20 attempt (completion, if successful or failure, if not), the result of=20 the attempt, and any additional information about a failure be=20 included in the string message.=20 It is suggested, but not required, that the messages be stored with=20 language tags (English, French, German, Japanese, Chinese, per [LANG=20 TAG]) particularly if multiple translations of the error messages are=20 available to the DSA implementers.=20 Note that this is a single-valued attribute. Sequences of status=20 entries SHOULD be written to log files or other persistent storage, or=20 in multi-valued replication history attributes, but are not specified=20 here.=20 6.2.5 replicaType=20 (2.16.840.1.113719.142.4.4 NAME 'replicaType'=20 DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 3-ReadOnly, all=20 others reserved'=20 EQUALITY integerMatch=20 SYNTAX INTEGER=20 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )=20 Reed [Page 9]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 ReplicaType is a simple enumeration, used to identify what kind of=20 replica is being described in a Replica object entry.=20 A ReadOnly replica only accepts LDAP Search operations (to Read=20 entries, list containers, and search for entries). Because no updates=20 ever originate from ReadOnly replicas, they never have changes to send=20 to another replica. However, a ReadOnly replica may be designated a=20 supplier DSA in a replica agreement, if it is simply passing along=20 information it receives from other Updateable replicas about entries=20 and their changes.=20 ReadOnly replicas may be incomplete replicas.=20 An Updateable replica may accept both LDAP Search operations (to read,=20 list, or search entries), as well as modification operations (to add,=20 modify, or delete entries). =20 The consequences of having incomplete updateable replicas are not=20 fully understood. LDAP DSAs MAY require updateable replicas to be=20 complete replicas.=20 A Primary replica is an Updateable replica, but it is "more special"=20 than other Updateable replicas. When LDAP application want to direct=20 their operations to a single replica, so that the application can be=20 sure that all application LDAP modification (add, delete, modify)=20 operations will be immediately visible to application readers, the=20 Primary replica is a good choice. Such a use would be consistent with=20 High Confidence DAP option [X518]. One such application might be a=20 management application which creates new naming contexts or joins two=20 naming contexts into a single naming context. Another application=20 might be one which creates new replicas, or replication agreements.=20 There SHOULD be only one Primary replica defined for a naming context=20 at any time. If applications, expecting there to be a Primary replica=20 discover, by search or inspection of ReplicaType attributes of the=20 defined Replicas of a naming context, find more than one _ they should=20 realize that something is wrong. =20 There MAY be NO primary replica defined for a naming context. =20 Primary replicas MAY NOT be incomplete replicas.=20 The way in which replicas change their type, as from ReadOnly to=20 Updateable, or Updateable to Primary is outside the scope of this=20 document.=20 Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible=20 combinations of replica types and sparse/fractional replicas.=20 Reed [Page 10]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 6.2.6 SecsToWait Attributes=20 The secsToWait attributes document the number of seconds a replica is=20 to wait after the occurrence of a "category n" change event before=20 initiating a new replication session for replicationAgreements=20 governed by an eventScheduledSubentry. The definition of a "category=20 n" change event is implementation dependent, and may be defined=20 differently by different directory servers. The absence of a value=20 for any of these attributes MUST be interpreted as meaning "do not=20 initiate a replication session for change events of this category". =20 6.2.6.1 secsToWaitCat1=20 ( 2.16.840.1.113719.142.4.5.1 NAME 'secsToWaitCat1'=20 SYNTAX INTEGER=20 USAGE dSAOperation )=20 6.2.6.2 secsToWaitCat2=20 ( 2.16.840.1.113719.142.4.5.2 NAME 'secsToWaitCat2'=20 SYNTAX INTEGER=20 USAGE dSAOperation )=20 6.2.6.3 secsToWaitCat3=20 ( 2.16.840.1.113719.142.4.5.3 NAME 'secsToWaitCat3'=20 SYNTAX INTEGER=20 USAGE dSAOperation )=20 6.2.6.4 secsToWaitCat4=20 ( 2.16.840.1.113719.142.4.5.4 NAME 'secsToWaitCat4'=20 SYNTAX INTEGER=20 USAGE dSAOperation )=20 6.2.6.5 secsToWaitCat5=20 ( 2.16.840.1.113719.142.4.5.5 NAME 'secsToWaitCat5'=20 SYNTAX INTEGER=20 USAGE dSAOperation )=20 Reed [Page 11]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 6.2.7 updateVector=20 ( 2.16.840.1.113719.142.4.6 NAME 'updateVector'=20 SYNTAX ldapChangeSequenceNumberSyntax=20 NO-USER-MODIFICATION USAGE dSAOperation )=20 The attribute updateVector is a multi-valued attribute which contains=20 information for a replica describing the latest changes received by=20 the replica from other replicas.=20 There may be only one ldapChangeSequenceNumber entry from each replica=20 in the updateVector. That is to say, there is a unique value=20 constraint on the ReplicaID component of entries in the list.=20 6.3 Class Definitions=20 6.3.1 nameContext=20 ( 2.16.840.1.113719.142.6.2.1 NAME 'nameContext' SUP top AUXILIARY )=20 The nameContext auxiliary class, when present on an object, indicates=20 the beginning, or root, of a naming context. The naming context is=20 said to be rooted at the entry with the nameContext auxiliary class in=20 its list of object classes. The root-most entry of a naming context=20 is the entry with the nameContext auxiliary class in its list of=20 object classes. =20 Characteristics of the replication topology of a naming context are=20 defined in the replicaSubentry sub-entries associated with the naming=20 context.=20 The attribute accessControlPolicyOID has been removed from here, and=20 should be published as an ldapSubEntry subordinate to the nameContext,=20 instead.=20 The attribute nameContextCreationTimestamp used here in previous=20 drafts has been eliminated as redundant. The ldapChangeSequenceNumber=20 associated with the nameContext value in the list of objectClasses=20 attribute serves the same purpose. =20 6.3.2 replicaSubentry=20 ( 2.16.840.1.113719.142.6.3.1 NAME 'replicaSubentry' SUP ldapSubEntry=20 STRUCTURAL=20 Reed [Page 12]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 MUST (cn, replicaURI, replicaType)=20 MAY (attributeExclusionFilter, attributeInclusionFilter,=20 description, updateVector) )=20 Entries of type replicaSubentry MAY be named by their cn attribute. =20 The attributes attributeExclusionFilter and attributeInclusionFilter,=20 if present, govern which entries and attributes from the local naming=20 context are to be sent (or not sent) to the replica named in replicaDN=20 of replica agreements for this replica. The attributeExclusionFilter=20 names attributes which SHOULD NOT be sent. The=20 attributeInclusionFilter names attributes which SHOULD be sent.=20 The attribute replicaURI contains information in ldapURI format that=20 can be used to contact (ie, open a connection to) this replica.=20 The attribute description contains a human-readable description of the=20 sub-entry. =20 The attribute updateVector contains a set of=20 ldapChangeSequenceNumbers, one for each of the other replicas for this=20 naming context, which records, from this replicas perspective, the=20 last change event received from the other indicated replica.=20 6.3.3 replicaAgreementSubentry=20 ( 2.16.840.1.113719.142.6.4.1 NAME 'replicaAgreementSubentry' =20 SUP ldapSubEntry STRUCTURAL=20 MUST ( cn )=20 MAY ( attributeExclusionFilter, description, replicaDN,=20 replicationMechanismOID, replicationStatus, scheduleDN ) ) =20 Entries of type replicaAgreementSubentry MAY be named by their cn=20 attribute.=20 The attributes attributeExclusionFilter, and ldapSearchFilter, if=20 present, govern which entries and attributes from the local naming=20 context are to be sent (or not sent) to the replica named in=20 replicaDN. The attributeExclusionFilter names attributes SHOULD NOT be=20 sent. Note there is no attributeInclusionFilter, because the list of=20 attributes that may be sent may not be extended beyond those=20 documented in the attributeInclusionFilter on the replicaSubentry.=20 Processing of allowable changes to be sent is as follows:=20 1) the attributeInclusionFilter from the replica subentry defines a=20 set of attributes which SHOULD be sent, less exclusions;=20 Reed [Page 13]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 2) the union of attributes excluded by the attributeExclusionFilter=20 from the replicasubentry and the attributeExclusionFilter from the=20 replicaAgreementSubentry defines a set of attributes which SHOULD=20 NOT be sent;=20 3) the subtraction of attributes which SHOULD NOT be sent by (2) from=20 the attributes which SHOULD be sent by (1) constitute the set of=20 attributes for which changes MAY be sent.=20 The attribute description contains a human-readable description of the=20 sub-entry.=20 The attribute replicaDN of syntax DN names another sub-entry of type=20 replicaSubentry to whom changes are to be sent. If there is no value=20 for the replicaDN attribute on a replicaAgreementSubentry, the=20 replicaAgreementSubentry is ignored. Absence of a value may occur=20 briefly when replicas and replica agreements are first being created,=20 or when the replica to which a replica agreement applies is being=20 deleted.=20 The attribute replicationStatus MAY be used to record the most recent=20 result of an attempt to send changes to the replica named in=20 replicaDN, whether success, or if failure, the nature of the problem=20 encountered.=20 The attribute schedule, if present, names one or more entries of type=20 scheduleSubentry which govern the schedule for replication attempts. =20 If not present, replication MUST be attempted when there are changes=20 to be sent.=20 6.3.4 eventScheduledSubentry Class=20 ( 2.16.840.1.113719.142.6.1.1 NAME 'eventScheduledSubentry' =20 SUP ldapSubEntry STRUCTURAL=20 MUST ( cn )=20 MAY ( description, secsToWaitCat1, secsToWaitCat2, secsToWaitCat3,=20 secsToWaitCat4, secsToWaitCat5 ) ) =20 Note that replication agreements using eventScheduledSubentry policy=20 are, by definition, supplier-initiated. =20 The description attribute may be used by the administrator to document=20 or comment on this subentry.=20 The secsToWaitCat1 attribute documents the number of seconds a replica=20 is to wait after the occurrence of a "category 1" change event before=20 initiating a new replication session for replicationAgreements=20 Reed [Page 14]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 governed by this eventScheduledSubentry. The definition of a=20 "category 1" change event is implementation dependent, and may be=20 defined differently by different directory servers. The absence of a=20 value for this attribute MUST be interpreted as meaning "do not=20 initiate a replication session for change events of this category". =20 The secsToWaitCat2 _ secsToWaitCat5 attributes are similarly defined=20 for their respective categoriess of change events.=20 6.3.5 timeScheduledSubentry Class=20 ( 2.16.840.1.113719.142.6.5.1 NAME 'timeScheduledSubentry' =20 SUP ldapSubEntry STRUCTURAL=20 MUST ( cn )=20 MAY ( description ) ) =20 7. Object Identifier Assignments=20 The LDUP OID prefix is =20 ID ::=3D OBJECT IDENTIFIER=20 ldup ID ::=3D { joint-iso-ccitt(2) country(16) us(840)=20 organization(1) novell(113719) ldup(142) }=20 The OID assignments defined in this document are:=20 Attributes:=20 attributeExclusionFilter ID ::=3D 2.16.840.1.113719.142.4.1=20 attributeInclusionFilter ID ::=3D 2.16.840.1.113719.142.4.2=20 replicationStatus ID ::=3D 2.16.840.1.113719.142.4.3=20 replicaType ID ::=3D 2.16.840.1.113719.142.4.4=20 secsToWaitClass1 ID ::=3D 2.16.840.1.113719.142.4.5.1=20 secsToWaitClass2 ID ::=3D 2.16.840.1.113719.142.4.5.2=20 secsToWaitClass3 ID ::=3D 2.16.840.1.113719.142.4.5.3=20 secsToWaitClass4 ID ::=3D 2.16.840.1.113719.142.4.5.4=20 secsToWaitClass5 ID ::=3D 2.16.840.1.113719.142.4.5.5=20 updateVector ID ::=3D 2.16.840.1.113719.142.4.6=20 Object Classes:=20 eventScheduledSubentry ID ::=3D 2.16.840.1.113719.142.6.1.1=20 nameContext ID ::=3D 2.16.840.1.113719.142.6.2.1=20 replicaSubentry ID ::=3D 2.16.840.1.113719.142.6.3.1=20 replicaAgreementSubentry ID ::=3D 2.16.840.1.113719.142.6.4.1=20 timeScheduledSubentry ID ::=3D 2.16.840.1.113719.142.6.5.1=20 Reed [Page 15]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 Note: Object Class OIDs have version numbers, Attribute OIDs don't.=20 8. Security Considerations=20 Many of the attributes and object classes described in this document=20 should be considered _security sensitive_, and protected from=20 unintended modification by LDAP servers. Generally, creating Naming=20 Contexts, Replicas and Replica Agreement entries should only be=20 allowed by directory administrators who are authorized to do so. =20 The values of attributes defined here are intended to control the=20 behavior of the directory service agents, themselves. Unintended=20 modification of their values may result in incomplete replication of=20 data (if ldapSearchFilter or attributeExclusionFilter are changed),=20 inappropriate disclosure of information (if attributeInclusionFilter=20 is changed), or updates may be lost (if updateVector is changed). =20 To avoid depending to much on the ldapAccessPoint values for other=20 replicas, connections between LDAP servers for the purpose of=20 replication MUST ALWAYS be authenticated using an authentication=20 mechanism appropriate for the nature of information to be exchanged.=20 9. References=20 [LANG TAG] _ M. Wahl, T. Howes, _Use of Language Codes in LDAP_,=20 Internet draft, draft-ietf-ldapext-lang-01.txt=20 [LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, _An Abstract Model=20 of LDAP Replication_, Internet draft, draft-merrells-ldup-model-01.txt=20 [LDUP Requirements] - R. Weiser, E. Stokes _LDAP Replication=20 Requirements_, Internet draft, draft-weiser-replica-req-02.txt, April=20 1998=20 [RFC2251] _ M. Wahl, T. Howes, S. Kille, _Lightweight Directory Access=20 Protocol (v3)_, December 1997, RFC 2251=20 [RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, _Lightweight=20 Directory Access Protocol (v3): Attribute Syntax Definitions_,=20 December 1997, RFC 2252=20 [X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997,=20 Information Technology _ Open Systems Interconnection _ The Directory: =20 Replication=20 Reed [Page 16]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995,=20 Information technology _ Abstract Syntax Notation One (ASN.1):=20 Specification of Basic Notation=20 10. Copyright Notice=20 Copyright (C) The Internet Society (1999). All Rights Reserved. =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implmentation may be prepared, copied, published and=20 distributed, in whole or in part, without restriction of any kind,=20 provided that the above copyright notice and this paragraph are=20 included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of developing=20 Internet standards in which case the procedures for copyrights defined=20 in the Internet Standards process must be followed, or as required to=20 translate it into languages other than English.=20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT=20 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN=20 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 11. Acknowledgements=20 The use of subEntry object class to store Replica and Replication=20 Agreement information is due primarily to the lucid explanation by=20 Mark Wahl, Innosoft, of how they could be used and extended.=20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to pertain=20 to the implementation or use of the technology described in this=20 document or the extent to which any license under such rights might or=20 might not be available; neither does it represent that it has made any=20 effort to identify any such rights. Information on the IETF's=20 procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of=20 Reed [Page 17]=20 Expires September 9, 2000=20 =0D=0C INTERNET-DRAFT 9 March 2000=20 LDUP Replication Information Model=20 rights made available for publication and any assurances of licenses=20 to be made available, or the result of an attempt made to obtain a=20 general license or permission for the use of such proprietary rights=20 by implementors or users of this specification can be obtained from=20 the IETF Secretariat.=20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights which may cover technology that may be required to practice=20 this standard. Please address the information to the IETF Executive=20 Director.=20 12. Author's Address=20 Edwards E. Reed=20 Reed-Matthews, Inc.=20 1064 East 140 North=20 Lindon, UT 84042=20 USA=20 E-mail: eer@oncalldba.com =20 =20 LDUP Mailing List: ietf-ldup@idc.org=20 Reed [Page 18]=20 Expires September 9, 2000=20 =0D=0C --=_BBE2474D.95F498AD-- From owner-ietf-ldup@mail.imc.org Fri Mar 10 18:47:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14157 for ; Fri, 10 Mar 2000 18:47:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA27999 for ietf-ldup-bks; Fri, 10 Mar 2000 14:09:45 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27995 for ; Fri, 10 Mar 2000 14:09:44 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA12546 for ; Fri, 10 Mar 2000 14:07:48 -0800 (PST) Received: from netscape.com ([208.12.63.184]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FR888V00.JJA for ; Fri, 10 Mar 2000 14:10:07 -0800 Message-ID: <38C97264.A1FC4C3@netscape.com> Date: Fri, 10 Mar 2000 14:08:36 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: [Fwd: draft-ietf-ldup-protocol-01.txt] Content-Type: multipart/mixed; boundary="------------1711693F225504027F59BEAA" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1711693F225504027F59BEAA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's the latest LDUP protocol draft. -Gordon --------------1711693F225504027F59BEAA Content-Type: message/rfc822 Content-Disposition: inline Message-ID: <38C94804.F298B63C@netscape.com> Date: Fri, 10 Mar 2000 11:07:48 -0800 From: Gordon Good X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: Gordon Good Subject: draft-ietf-ldup-protocol-01.txt Content-Type: multipart/mixed; boundary="------------B59AD23CBD4CB2E77DA97ADB" This is a multi-part message in MIME format. --------------B59AD23CBD4CB2E77DA97ADB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Editor, Please publish the attached internet draft. It is an update to draft-ietf-ldup-protocol-00.txt. --------------B59AD23CBD4CB2E77DA97ADB Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ldup-protocol-01.txt" Content-Disposition: inline; filename="draft-ietf-ldup-protocol-01.txt" Content-Transfer-Encoding: 7bit LDUP Replication Update Protocol Internet-Draft Intended Category: Standards Track Expires: September 10, 2000 Ellen Stokes IBM Corporation Gordon Good Netscape Communications Corp. March 10 2000 The LDUP Replication Update Protocol Filename: draft-ietf-ldup-protocol-01.txt Table of Contents 1. Status of this Memo.............................................2 2. Abstract........................................................2 3. Overview of Protocol............................................2 4. High-level Description of Protocol Flow.........................3 4.1 Supplier-initiated incremental replication protocol.............3 4.2. Consumer-initiated replication protocol......................4 5. Replication protocol element definitions........................5 5.1 StartFramedProtocolRequest Extended Operation...................5 5.2 StartFramedProtocolResponse Extended Operation..................6 5.3 ReplicationUpdate Extended Operation............................7 5.3.1 UniqueIdentifier.............................................8 5.3.2 ReplicationPrimitive.........................................8 5.3.2.1 AddEntryPrimitive.........................................8 5.3.2.2 MoveEntryPrimitive........................................9 5.3.2.3 RenameEntryPrimitive......................................9 5.3.2.4 RemoveEntryPrimitive......................................9 5.3.2.5 AddAttributeValuePrimitive................................10 5.3.2.6 RemoveAttributeValuePrimitive.............................10 5.3.2.7 RemoveAttributePrimitive..................................10 5.4 EndFramedProtocolRequest Extended Operation.....................11 5.5 EndFramedProtocolResponse Extended Operation....................11 5.6 ReplicationUpdateResponse Extended Operation....................12 6. Semantics of Full and Incremental Update protocols..............13 7. Summary of response codes.......................................13 8. Implications for log-based and state-based servers..............13 9. Replication of access control and schema information............13 10. Security Considerations.........................................14 11. Glossary of Terms...............................................14 12. Acknowledgments.................................................14 13. References......................................................14 14. Author's Addresses..............................................15 Stokes and Good [Page 1] Internet-Draft LDUP Workgroup March 10 2000 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet Draft expires September 10, 2000. 2. Abstract The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updatable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. Certain terms used in this document are defined in the document "LDAP Replication Architecture" (draft-ietf-ldup-model-00.txt). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 3. Overview of Protocol The LDAP Replication Architecture [ARCHITECTURE] describes the overall approach used in ensuring consistency of multiple updatable replicas of directory content. The protocol described in this document implements the approach desribed in that document. Stokes and Good [Page 2] Internet-Draft LDUP Workgroup March 10 2000 LDAP Version 3 extended operations are used to carry replicated content from one server to another. The extended operations defined in this document are used to initiate and end a replication session, and to exchange updates. These updates carry with them information that allows the receiving server to apply a total ordering to all of the updates in a replicated system. All servers that receive replication updates apply a consistent set of update resolution policies, described in [URP]. Consistent application of the update resolution policies ensures that all replicas eventually converge and contain the same directory data. This protocol is based upon the extended operations defined in [FRAMING]. This protocol is intended to meet the requirements set forth in [REQ]. 4. High-level Description of Protocol Flow The following section provides a high-level overview of the replication protocol. Throughout this section, the supplier server is indicated by the letter "S" and the consumer server by the letter "C". The construct "S -> C" indicates that the supplier is sending an LDAPv3 extended operation to the consumer, and "C -> S" indicates that the consumer is sending an LDAPv3 extended operation to the supplier. 4.1 Supplier-initiated incremental replication protocol S -> C: LDAP bind operation (identity and credentials used are implementation-defined) C -> S: Bind response S -> C: StartFramedProtocolRequest LDAPv3 extended operation. The parameters are: 1) The OID for the LDUP incremental replication protocol or the LDUP total update protocol, depending on whether an incremental or complete refresh of the replica is to be performed. 2) A protocol-specific payload containing: a) The root of replicated area (unambiguously identifies the replicated area) b) The supplier's replicaID c) The protocol initiation type - Supplier-Initiated in this case. C -> S: StartFramedProtocolResponse LDAPv3 extended operation. The Stokes and Good [Page 3] Internet-Draft LDUP Workgroup March 10 2000 parameters are: 1) A protocol-specific payload containing: a) A response code (see section 7) b) An optional update vector that is included if and only if the response code is REPL_SUCCESS. S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3 extended operations. The parameters are: 1) The UUID of the entry being updated 2) One or more Replication Primitives (The supplier may send as many of these as required to bring the consumer up to date) C -> S: At any time, the consumer may send an unsolicited ReplicationUpdateResponse LDAPv3 extended operation. The parameters are: 1) An optional update vector. If sent, this indicates that the consumer has committed all updates whose CSNs are covered by the transmitted update vector [see glossary for a definition of "covered by"]. 2) An optional AbortUpdate boolean flag. If a supplier receives a ReplicationUpdateResponse from a consumer with the AbortUpdate flag set to true, the supplier server MUST immediately cease sending updates and terminate its connection to the consumer. S -> C: After all required updates have been sent to the consumer, the supplier sends an EndFramedProtocolRequest LDAPv3 extended operation. C -> S: The consumer responds by sending an EndFramedProtocolResponse LDAPv3 extended operation, and then closes the connection. 4.2. Consumer-initiated replication protocol C -> S: LDAP bind operation (identity and credentials used are implementation-defined) S -> C: Bind response C -> S: StartFramedProtocolRequest LDAPv3 extended operation. The parameters are: 1) The OID for the LDUP incremental replication protocol or the LDUP total update protocol, depending on whether an incremental Stokes and Good [Page 4] Internet-Draft LDUP Workgroup March 10 2000 or complete refresh of the replica is to be performed. 2) A protocol-specific payload containing: a) The root of replicated area (unambiguously identifies the replicated area) b) The consumer's replicaID c) The protocol initiation type - Consumer-Initiated in this case. S -> C: StartFramedProtocolResponse LDAPv3 extended operation. The parameters are: 1) A protocol-specific payload containing: a) A response code (see section 7) S -> C: The supplier server disconnects from the consumer server, and then connects to the consumer, beginning a Supplier- Initiated protocol session (see section 4.1). 5. Replication protocol element definitions 5.1 StartFramedProtocolRequest Extended Operation The StartFramedProtocolRequest extended operation is sent by a replication initiator to a server to indicate that a replication session should commence. For supplier-initiated replication, the supplier sends this extended operation to the replication consumer to indicate that a replication session should commence. For consumer-initiated replication, the consumer sends this extended operation to the replication supplier to indicate that the supplier should initiate a replication session to the consumer as soon as possible. The StartFramedProtocolRequest extended operation is defined in [FRAMING]. When signaling the beginning of a replication session, then requestValue of the StartFramedProtocolRequest is set to the following: requestValue ::= SEQUENCE { framedProtocolOID LDAPOID, framedProtocolPayload OPTIONAL OCTET STRING } The framedProtocolOID of the StartReplicationRequest must be the OID for the LDUP incremental replication protocol, 2.16.840.1.113719.1.142.1.4.3, or the LDUP total update protocol, 2.16.840.1.113719.1.142.1.4.4. See section 7 for information on the semantic behavior of these update protocols. Implementations MUST support the two update protocols defined in this document. Stokes and Good [Page 5] Internet-Draft LDUP Workgroup March 10 2000 The framedProtocolPayload of the StartFramedProtocolRequestValue must be set to the BER-encoding of the following: framedProtocolPayload ::= SEQUENCE { replicaRoot LDAPDN, replicaID LDAPString, replicationInitiator ENUMERATED { supplier (0), consumer (1) } } The parameters in the framedProtocolPayload of the StartFramedProtocolRequestValue are: - replicaRoot: the distinguished name of the entry at the top of the replicated area, and uniquely identifies the unit of replication. - replicaID: the replica identifier of the replication initiator. Each replica of a given replicated area is identified by a unique identifier, described in [ARCHITECTURE]. - replicationInitiator: used to differentiate between a supplier- initiated session and a consumer-initiated session. If the replicationInitiator contains the enumerated value , then the initiator is the supplier, and the receiver of this operation should prepare to receive a set of replication updates (or should reject the operation is replication updates are not permitted for some reasonm, perhaps due to access control restrictions). If the replicationInitiator contains the enumerated value , then the receiver should prepare to establish a supplier-initiated replication session with the consumer as soon as possible, updating the replicated are given by replicaRoot and using the update protocol given by replicationProtocolOID. 5.2 StartFramedProtocolResponse Extended Operation The StartFramedProtocolResponse extended operation is sent in response to a StartFramedProtocolRequest extended operation. For a supplier-initiated session, the response field of the StartFramedProtocolResponse extended response indicates that the consumer is or is not prepared to accept a set of updates. If the consumer is prepared to accept updates, it sends a response field containing a success code and the consumer's replica update vector. If the consumer is unwilling or unable to accept updates, it sends a Stokes and Good [Page 6] Internet-Draft LDUP Workgroup March 10 2000 response field containing an error code. For a consumer-initiated session, the response field of the StartFramedProtocolResponse extended respons indicates that the supplier is or is not prepared to send a set of updates to the consumer. If the supplier is prepared to send updates to the consumer, it sends a response field containing a success code. If the supplier is unwilling or unable to send updates to the consumer, it sends a response field containing an error code. In both cases, the supplier disconnects from the consumer. If the supplier sent a success code to the consumer, it opens a connection to the consumer as soon as possible and initiates a supplier-initiated replication session. The StartFramedProtocolResponse extended operation is defined in [FRAMING]. When responding to a StartFramedProtocolRequest signaling the beginning of an LDUP replication session, the response field of the StartFramedProtocolResponse is set to the following: StartFramedProtocolResponseValue ::= SEQUENCE { responseCode LDUPResponseCode, replicaUpdateVector Attribute, } LDUPResponseCodes are defined in section 8. The replicaUpdateVector contains a replica update vector, as defined in [INFOMOD]. The update vector is encoded as a normal LDAP attribute, defined in [LDAPv3]. 5.3 ReplicationUpdate Extended Operation The ReplicationUpdate extended operation carries a set of replication primitives that represent the desired final state of a single entry. The ReplicationUpdate extended operation is defined as follows: An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID requestValue [1] OCTET STRING OPTIONAL } The requestName of the ReplicationUpdate must be the OID 2.16.840.1.113719.1.142.100.3. Stokes and Good [Page 7] Internet-Draft LDUP Workgroup March 10 2000 The requestValue of the ReplicationUpdate must be set to the BER- encoding of the following: requestValue ::= SEQUENCE { uniqueID UniqueIdentifier, updates SET OF ReplicationPrimitive } 5.3.1 UniqueIdentifier The Distinguished Name of an entry may be changed (by renaming the entry), or the entry may not have a distinguished name (if it was deleted). The Unique Identifier provides an immutable name, independent of the current name or deletion status, for an entry. All replicated operations address entries by their Unique Identifiers. UniqueIdentifier ::= LDAPString 5.3.2 ReplicationPrimitive A ReplicationPrimitive carries a single assertion about the the final state of an entry, attribute, or attribute value. There are seven types of primitives. ReplicationPrimitive ::= CHOICE { addEntryPrimitive AddEntryPrimitive, moveEntryPrimitive MoveEntryPrimitive, renameEntryPrimitive RenameEntryPrimitive, removeEntryPrimitive RemoveEntryPrimitive, addAttributeValuePrimitive AddAttributeValuePrimitive, removeAttributeValuePrimitive RemoveAttributeValuePrimitive, removeAttributePrimitive RemoveAttributePrimitive } Each primitive applies to the entry referred to by the uniqueIdentifier in the enclosing ReplicationUpdate extended operation. Each primitive carries an lLDAPChangeSequenceNumber that is used by the consumer server to correctly resolve update conflicts. [URP] describes the update reconciliation procedures. 5.3.2.1 AddEntryPrimitive The AddEntryPrimitive is used to add a new entry. AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE { Stokes and Good [Page 8] Internet-Draft LDUP Workgroup March 10 2000 csn lDAPChangeSequenceNumber, superior UniqueIdentifier, rdn RelativeLDAPDN } Parameters of the AddEntryPrimitive are: - csn: The change sequence number of the primitive. - superior: The unique identifier of the superior (parent) entry. - rdn: The relative distinguished name of the new entry. 5.3.2.2 MoveEntryPrimitive The MoveEntryPrimitive is used to move an entry to a new location in the DIT. MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE { csn lDAPChangeSequenceNumber, superior UniqueIdentifier } Parameters of the MoveEntryPrimitive are: - csn: The change sequence number of the primitive. - superior: The unique identifier of the new superior (parent) entry. 5.3.2.3 RenameEntryPrimitive The RenameEntryPrimitive is used to change the RDN of an entry. RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE { csn lDAPChangeSequenceNumber, rdn RelativeLDAPDN } Parameters of the RenameEntryPrimitive are: - csn: The change sequence number of the primitive. - rdn: The new relative distinguished name of the entry. 5.3.2.4 RemoveEntryPrimitive The RemoveEntryPrimitive is used to delete an entry from the DIT. Stokes and Good [Page 9] Internet-Draft LDUP Workgroup March 10 2000 RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE { csn lDAPChangeSequenceNumber } Parameters of the RemoveEntryPrimitive are: - csn: The change sequence number of the primitive. 5.3.2.5 AddAttributeValuePrimitive The AddAttributeValuePrimitive is use to add a new attribute value to an entry. AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription, value AttributeValue } Parameters of the AddAttributeValuePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being added. - value: The value being added. Multiple values are not permitted. 5.3.2.6 RemoveAttributeValuePrimitive The RemoveAttributeValuePrimitive is used to remove a particular attribute value from an entry. RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription, value AttributeValue } Parameters of the RemoveAttributeValuePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being removed. - value: The value being removed. Multiple values are not permitted. 5.3.2.7 RemoveAttributePrimitive Stokes and Good [Page 10] Internet-Draft LDUP Workgroup March 10 2000 The RemoveAttributePrimitive is used to remove an attribute and all its values from an entry. RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE { csn lDAPChangeSequenceNumber, type AttributeDescription } Parameters of the RemoveAttributePrimitive are: - csn: The change sequence number of the primitive. - type: The type of the attribute being removed. 5.4 EndFramedProtocolRequest Extended Operation The EndFramedProtocolRequest extended operation is sent from the replication supplier to the replication consumer to indicate the end of the sequence of replication updates. In the event that the supplier is sending a total update, the requestValue field of the EndFramedProtocolRequest extended operation contains a replica update vector. The consumer server must replace its replica update vector, if present, with the one provided by the supplier. In the event that the supplier is sending an incremental update, the replica update vector is absent. The EndFramedProtocolRequest extended operation is defined in [FRAMING]. When used to signal the termination of an LDUP incremental or total update session, the requestValue field of the EndFramedProtocolRequest is set to the following: requestValue ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL, returnConsumerUpdateVector BOOLEAN } If returnConsumerUpdateVector is TRUE, the consumer server must return its current update vector to the supplier in the response field of the EndFramedProtocolResponse extended response (defined in section 5.5). Typically, the supplier will request the consumer's update vector for read-only replicas, since the read-only replica will never initiate a replication session, and will therefore never have the opportunity to provide its update vector to other servers. 5.5 EndFramedProtocolResponse Extended Operation Stokes and Good [Page 11] Internet-Draft LDUP Workgroup March 10 2000 The EndFramedProtocolResponse extended operation is defined in [FRAMING]. It is used to respond to a EndFramedProtocolRequest. The response field of the EndFramedProtocolResponse extended operation is set to the following: response ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL } The replicaUpdateVector contains the consumer's current replica update vector, and is optional. The consumer server should only send the replicaUpdateVector if requested by the supplier server in the EndReplicationRequest extended operation. 5.6 ReplicationUpdateResponse Extended Operation The ReplicationUpdateResponse extended operation is sent, unsolicited, by a consumer to a supplier when the consumer wishes the supplier to stop sending updates. An LDAPv3 extended response is defined in [LDAPv3] as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the ReplicationUpdateResponse must be the OID [OID to be assigned]. The response field of the ReplicationUpdateResponse must be set to the BER-encoding of the following: response ::= SEQUENCE { replicaUpdateVector Attribute OPTIONAL abortUpdate BOOLEAN } The parameters of the ReplicationUpdateResponse are: - An optional update vector. If sent, this indicates that the consumer has committed all updates whose CSNs are covered by the transmitted update vector [see glossary for a definition of "covered by"]. - An optional AbortUpdate boolean flag. If a supplier receives a ReplicationUpdateResponse from a consumer with the AbortUpdate flag set to true, the supplier server MUST immediately cease sending updates and terminate its connection to the consumer. Stokes and Good [Page 12] Internet-Draft LDUP Workgroup March 10 2000 6. Semantics of Full and Incremental Update protocols [To be written] 7. Summary of response codes The following list describes the response codes that may be included in the StartFramedProtocolResponse, EndFramedProtocolResponse, and ReplicationUpdateResponse extended operations. LDUPResponseCode ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), insufficientAccessRights (50), busy (51), excessiveCSNSkew (200), other (80) }, errorMessage LDAPString } The meanings of the response codes are as follows: success..................... As defined in [LDAPv3]. operationsError............. As defined in [LDAPv3]. protocolError............... As defined in [LDAPv3]. insufficientAccessRights.... Access denied. The identity that the initiator provided in the bind request does not have sufficient privileges to perform the operation. busy........................ The replica is temporarily unable to accept updates. excessiveCSNSkew............ The consumer server has detected that the CSNs being generated by the supplier are too small (perhaps because the supplier's clock was set back). Updates from the supplier will not be applied. other....................... Some other error occurred. 8. Implications for log-based and state-based servers To be written, or possibly incorporated into [ARCHITECTURE]. 9. Replication of access control and schema information To be written, or possibly incorporated into [ARCHITECTURE]. Stokes and Good [Page 13] Internet-Draft LDUP Workgroup March 10 2000 10. Security Considerations To be written. 11. Glossary of Terms Covered by: We say that a CSN is "covered by" an update vector if and only if the CSN is less than or equal to the component of the update vector corresponding to the replica ID in the CSN. In other words, given a CSN with components and an update vector with CSNs ,..., then the CSN is covered by the RUV if and only if one of the following holds for some value i: a) r = ri and t < ti b) r = ri and t = ti and S < Si c) r = ri and t = ti and S = Si and s < si 12. Acknowledgments To be written. 13. References [ARCHITECTURE] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec- ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999. [FRAMING] E. Stokes, G. Good, "Extended Operations for Framing LDAP Bulk Update Operations", Internet-Draft, draft-ietf-ldup-framing-00.txt, March 2000. [INFOMOD] E. Reed, "LDAP Replication Information Model", Internet-Draft, draft-reed-ldup-infomod-00.txt, June 1999. [KEYWORDS] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- els", Harvard University, RFC 2119, March 1997. [LDAPv3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol Stokes and Good [Page 14] Internet-Draft LDUP Workgroup March 10 2000 (v3)", RFC 2251, December 1997. [REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements", Internet-Draft, draft-ietf-ldup-replica-req-02.txt, October 1999. [URP]S. Legg, A. Payne, "LDUP Update Reconciliation Procedures", Internet-Draft, draft-ietf-ldup-urp-02.txt, October 1999. 14. Author's Addresses Ellen Stokes IBM 11400 Burnet Rd Austin, TX 78758 USA EMail: stokes@austin.ibm.com phone: +1 512 838 3725 fax: +1 512 838 0156 Gordon Good Netscape Communications Corp. 501 E. Middlefield Rd. Mailstop MV068 Mountain View, CA 94043 USA EMail: ggood@netscape.com Phone: +1 650 937-3825 15. Document Revision History (This section will be removed prior to this document's publication as a proposed standard) Differences between draft-ietf-ldup-protocol-00.txt and draft-ietf-ldup-protocol-01.txt: 1) The document was reworked to use the ldup framed protocol draft [FRAMING]. Appendix A - Complete ASN.1 Definition To be written. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. Stokes and Good [Page 15] Internet-Draft LDUP Workgroup March 10 2000 This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Stan- dards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- NESS FOR A PARTICULAR PURPOSE. Stokes and Good [Page 16] --------------B59AD23CBD4CB2E77DA97ADB-- --------------1711693F225504027F59BEAA-- From owner-ietf-ldup@mail.imc.org Mon Mar 13 12:38:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09378 for ; Mon, 13 Mar 2000 12:38:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17377 for ietf-ldup-bks; Mon, 13 Mar 2000 08:56:42 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17373 for ; Mon, 13 Mar 2000 08:56:41 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA22773 for ; Mon, 13 Mar 2000 08:54:56 -0800 (PST) Received: from netscape.com ([208.12.63.184]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FRDDRH00.A14; Mon, 13 Mar 2000 08:57:17 -0800 Message-ID: <38CD1D97.94C1446@netscape.com> Date: Mon, 13 Mar 2000 08:55:51 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: <38BEE2B6.BE3DF1D2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've refreshed the changelog draft. It's now available from the IETF Internet Drafts repository: http://www.ietf.org/internet-drafts/draft-good-ldap-changelog-01.txt -Gordon From owner-ietf-ldup@mail.imc.org Mon Mar 13 18:43:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29713 for ; Mon, 13 Mar 2000 18:43:54 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA26756 for ietf-ldup-bks; Mon, 13 Mar 2000 15:07:22 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA26752 for ; Mon, 13 Mar 2000 15:07:19 -0800 (PST) Received: (qmail 30546 invoked from network); 13 Mar 2000 23:08:13 -0000 Received: from softdnserror (HELO rubidium) (203.8.85.137) by arnie.adacel.com.au with SMTP; 13 Mar 2000 23:08:13 -0000 Reply-To: From: "Steven Legg" To: "'Jim Sermersheim'" Cc: , Subject: RE: LDAP subentry, discussion on CN {MUST or MAY} Date: Tue, 14 Mar 2000 10:09:57 +1100 Message-ID: <000801bf8d41$42668970$895508cb@rubidium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim, I agree with your interpretation, with the added qualification that the naming attribute(s) must still be a permitted attribute of the entry, if not by the structural object class then by an auxiliary object class or DIT content rule. That is, being referenced in a relevant name form does not alone make an attribute a permitted attribute of an entry. For the record, I'm not much fussed whether we make the cn attribute mandatory or not, but if the definition of LDAPsubentry ends up being the same as X.500's subentry definition I would rather that we just copy the X.500 definition and OID. Steven -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jim Sermersheim Sent: Friday, 10 March 2000 16:22 To: jayhawk@att.com; kurt@boolean.net; eskovgaard@geotrain.com; era.als@get2net.dk; mcs@netscape.com; eer@OnCallDBA.COM Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com; Mark Hinckley Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} To satisfy X.500, I believe that the LDAPSubentry object class can be STRUCTURAL and not include any attributes. From my reading, the attributes specified in the name form don't need to be made up of the attributes specified in the object class definition. The text I'm reading is in Section 12.6.2 of X.501: "The RDN attribute (or attributes) need not be chosen from the list of permitted attributes of the structural object class as specified in its structural or alias object class definition". I may be mis-reading that, but I don't think so. There also may be directory implementations that require naming attributes to be listed in the object class's MUST or MAY list (I know of at least one). Jim >>> "Ed Reed" 3/9/00 2:58:31 PM >>> Back in November and at the IETF meeting in Washington, we discussed whether LDAPsubentry should be STRUCTURAL or ABSTRACT in definition. Mark has pointed out that MAY would address Kurt's objection to MUST {cn}, but that leaves the many folks out there who define naming rules with a problem, when there are (possibly) no attributes defined on the class at all (cn is the only attribute declared for the ldapsubentry class definition). Frankly, those folks who DO define naming attributes and naming rules will have to deal in some way with other systems who don't, but that's a different discussion I think. I think the discussion in Washington concluded that we should 1) leave the class STRUCTURAL 2) leave MUST {cn} in the definition 3) encourage Kurt to derive a new subclass of LDAPsubentry for his special-purpose class, which defines the other attribute he will use to actually name his entries - meaning that yes, he will need to provide a (possibly useless, but not necessarily unique) value for the cn value Erik's argument, that to make it Auxiliary would require a proliferation of new structural types, each with their own new naming rules, is what finally persuaded me to avoid that approach. The consequences of blithly ignoring the operational experience of the X.500 community was also important. It will be easier, by far, for most people to treat LDAPsubentry as STRUCTURAL, and then to decorate it with additional attributes for their particular needs, than to require each new use to define a new STRUCTURAL class with it's own naming rules. As I think about it, though, there is one way to make both camps happy: 1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. 2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). Such an approach would violate the "fewer classes is better" rule. But I think it would satisfy both Kurt and the X.500 folks. This is the only issue standing in the way of a last call. Any final words? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM From owner-ietf-ldup@mail.imc.org Mon Mar 13 19:18:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13123 for ; Mon, 13 Mar 2000 19:18:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA27340 for ietf-ldup-bks; Mon, 13 Mar 2000 15:48:36 -0800 (PST) Received: from infidel.boolean.net (root@router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27336 for ; Mon, 13 Mar 2000 15:48:35 -0800 (PST) Received: from gypsy (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with SMTP id XAA17604; Mon, 13 Mar 2000 23:49:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <3.0.5.32.20000313154921.009508d0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 13 Mar 2000 15:49:21 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: LDAP subentry, discussion on CN {MUST or MAY} Cc: "'Jim Sermersheim'" , , In-Reply-To: <000801bf8d41$42668970$895508cb@rubidium.adacel.com.au> References: 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:09 AM 3/14/00 +1100, Steven Legg wrote: >For the record, I'm not much fussed whether we make the cn attribute >mandatory or not, but if the definition of LDAPsubentry ends up being the >same as X.500's subentry definition I would rather that we just copy >the X.500 definition and OID. LDAPsubentry is quite dissimiliar in definition to the X.500 subentry. It doesn't allow have a subtree specifier. Hence, the new OID. From owner-ietf-ldup@mail.imc.org Tue Mar 14 06:54:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03685 for ; Tue, 14 Mar 2000 06:54:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA02493 for ietf-ldup-bks; Tue, 14 Mar 2000 03:19:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02486 for ; Tue, 14 Mar 2000 03:19:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19975; Tue, 14 Mar 2000 06:20:44 -0500 (EST) Message-Id: <200003141120.GAA19975@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-subentry-02.txt Date: Tue, 14 Mar 2000 06:20:43 -0500 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 Subentry Schema Author(s) : E. Reed Filename : draft-ietf-ldup-subentry-02.txt Pages : 5 Date : 13-Mar-00 This document describes an object class called ldapSubEntry which MAY be used to indicate operations and management related entries in the directory, called LDAP Subentries. This version of this document is updated with an assigned OID for the ldapSubEntry object class. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-02.txt 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-subentry-02.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-subentry-02.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: <20000313135919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-subentry-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-subentry-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135919.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Mar 14 18:30:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05921 for ; Tue, 14 Mar 2000 18:30:25 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA19082 for ietf-ldup-bks; Tue, 14 Mar 2000 14:56:07 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19078 for ; Tue, 14 Mar 2000 14:56:06 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA20950 for ; Tue, 14 Mar 2000 14:52:15 -0800 (PST) Received: from netscape.com ([207.1.151.46]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FRFP2P00.C0L; Tue, 14 Mar 2000 14:56:49 -0800 Message-ID: <38CEC3C0.BEF5F73D@netscape.com> Date: Tue, 14 Mar 2000 14:57:04 -0800 From: olga@netscape.com (Olga Natkovich) X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ryan Moats CC: ietf-lcup@netscape.com, ietf-ldup@imc.org, Richard V Huber Subject: Re: Oops: comments on LCUP draft References: <001e01bf8ac4$87aabd00$e3c8090a@schooner.local.windrose.omaha.ne.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Thank you for your feedback. My comments are inline below. Ryan Moats wrote: > (That's what I get for not paying attention to > subject lines. This is a resend with a correct > subject. Sigh) > > Having read the LCUP draft, we're concerned that this doesn't > seem to address the issues that were identified with either > the old or new Persistent and Triggered searches drafts. > > A noticeable point is that the definition doesn't distinguish > (at the protocol message level) between the cases where > a server shuts down a connection normally and where it > shuts down a connection because of resource exhaustion. > Further, the draft needs to provide some guidance/mandate > on client behavior in the second case. Without it, what's > to stop a client from reconnecting and resubmitting the > control (and how does that help resource exhaustion)? Good point. The server should send an appropriate error code to the client. I will define a control that will be attached to the SearchResultDone message and will contain the error code. I will also add the information on client's behavior; I was thinking something along the lines of exponential backoff. > The LCUP draft might want to contain something along the lines of the > "Implementation Considerations" section of the new psearch draft. The > intended use discussion raises some interesting scale issues that LCUP > should address. Ok, I will add that. > LCUP draft should mention whether any other LDAP requests/responses can > be sent via the open connection while a keepConnection request is > active (The draft doesn't seem to say. We hope the answer is > "none apart from the usual suspects like ABANDON"). I am not sure why it would be beneficial to disallow other operations on the same connection. Since each request/response pair carries a message id, no ambiguity could arise. Also, allowing operations on the same connection would allow to conserve server's resources. > Why MUST a stateUpdate message contain a valid entry? By valid entry I meant an entry that contained a valid DN to comply with LDAP v3 definition of the SearchResultEntry. I will clarify this in the draft. > If the client sends the server a bad cookie, the server sends back > unwillingToPerform. Is there some problem in generating a more specific > error? Using a really general error seems like it might lead to a lot > of customer service support time to track down the real problem. The only problem was the need for a new control. However, this seems like the right thing to do. So the control described above will be used. > Why SHOULD size and time limits be ignored for persistent operations? > Why not MUST? Right, this should be MUST. > The Security Considerations address the issue of limiting resources > that are accessed by a single client, but don't seem to address the > same issues if the "attacker" just uses several clients. This problem is not specific to LCUP; the same problem exists in LDAP and a lot of other client-server applications. Mark Smith suggested that we do the following: "... you can require authentication and restrict use of LCUP to some clients, but if the attacker gets a hold of an identity that is allowed to use LCUP life is hard. We could suggest limiting how many different simultaneous connections can be used for LCUP that are bound to the same identity (e.g., "Bob Smith is allowed to use LCUP but only on 2 connections at a time.") Implementation of such a restriction would be server-specific for now but could be rolled into the LDAPv3 access control standard. Olga From owner-ietf-ldup@mail.imc.org Wed Mar 15 06:58:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12262 for ; Wed, 15 Mar 2000 06:58:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA26332 for ietf-ldup-bks; Wed, 15 Mar 2000 03:23:46 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26328 for ; Wed, 15 Mar 2000 03:23:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29515; Wed, 15 Mar 2000 06:25:01 -0500 (EST) Message-Id: <200003151125.GAA29515@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-protocol-01.txt Date: Wed, 15 Mar 2000 06:25:00 -0500 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 : The LDUP Replication Update Protocol Author(s) : E. Stokes, G. Good Filename : draft-ietf-ldup-protocol-01.txt Pages : 16 Date : 14-Mar-00 The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updatable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-01.txt 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-protocol-01.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-protocol-01.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: <20000314133049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314133049.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Mar 15 15:40:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18298 for ; Wed, 15 Mar 2000 15:40:19 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA14360 for ietf-ldup-bks; Wed, 15 Mar 2000 11:45:39 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA14356 for ; Wed, 15 Mar 2000 11:45:35 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 15 Mar 2000 12:46:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 15 Mar 2000 12:46:06 -0700 From: "Roger Harrison" To: Subject: Submission of draft-rharrison-lburp-01.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_EAB3109D.ACCDD32B" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_EAB3109D.ACCDD32B Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I submitted this latest version of the LBURP draft last week, but I = haven't seen it come through the standard Internet-Drafts channel yet. = Your comments and input are appreciated. A list of changes made since version 00 is given in section 10. Document = Revision History. Thanks, Roger Harrison --=_EAB3109D.ACCDD32B Content-Type: text/plain Content-Disposition: attachment; filename="draft-rharrison-lburp-01.txt" Individual Submission to ldup working group R. Harrison Internet Draft J. Sermersheim Document: draft-rharrison-lburp-01.txt Novell, Inc. Category: Proposed Standard March, 2000 LDAP Bulk Update/Replication Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The protocol described in this document allows an LDAP client (a genuine client or an LDAP server acting as a client) to perform a bulk update to a replica on an LDAP server. The protocol groups a set of update operations using the LDAP framed protocol requests defined in [FRAMING] to notify the client that the update operations in the framed set are related. The update operations within the framed set are LDAP v3 extended operations each containing a sequence number and one or more update LDAP v3 update operations. The sequence number allows the server to process the update operations in the proper order even when they are sent asynchronously by the client, and the update operations can be grouped within the extended request to maximize the efficiency of client-server communication. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally change the existing entries in an LDAP replica. It is suitable for client utilities that need to efficiently initialize a replica with many entries or efficiently make a substantial set of update changes to a replica. It is also suitable as a protocol for replication between a single master replica and its slave replicas. Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 1 LDAP Bulk Update/Replication Protocol March, 2000 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ReqsKeywords]. The term supplier applies to an LDAP client or and LDAP server (acting as a client) that supplies a set of update operations to a consumer. The term consumer applies to an LDAP server that consumes (processes) the update operations sent to it by a supplier. 3. Motivation for protocol This protocol arose from the need to allow LDAP clients to efficiently present large quantities of updates to an LDAP server and have the LDAP server efficiently process them. This protocol introduces a minimum of new operational functionality to the LDAP protocol since the update requests sent by the client encapsulate standard LDAP [LDAPv3] update operations. However, this protocol greatly facilitates this process by allowing the client to present the update operations asynchronously and still allow the server to maintain proper ordering of the operations. It also allows the server to recognize the client’s intent to perform a potentially large set of update operations and then to change its processing strategy to be more efficient than it otherwise could be. In effect, this protocol gives a hint to the server that the LDAP operations framed within it can be treated in a special way because they are related to each other. The server may then take actions that would not otherwise be practical to speed the processing of the updates. Examples of such actions include refusing to perform operations for other clients during the update sequence and grouping update operations into a single transaction rather than applying them to the DIT singly. Additionally, this protocol deals with a common interoperability problem in this space caused by implementations having different requirements and abilities for handling linear and circular dependencies as entries are created. A common application of this protocol is anticipated to be the initialization or update of an LDAP replica from a set of records represented in an [LDIF] file. Due to the abilities of various implementations, these files often contain "out-of-order" records where an entry is created before its parent or it is made a member of a group before the member's entry has been created. Some implementations create temporary holding objects to deal with these issues, but others do not. This protocol allows the server to reorder update operations in a limited way to deal with such cases. Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 2 LDAP Bulk Update/Replication Protocol March, 2000 4. Overview of protocol The bulk replication/update protocol utilizes framing described in [FRAMING] to group a set of update operations to be applied to a naming context. The update operations are sent via LDAP v3 extended operations, each of which contains a sequence number and a list of one or more update operations to be performed by the consumer. Except for the fact that they are grouped together as part of a larger LDAP v3 extended request, the update operations in each subset are normal LDAP v3 update operations and use the encoding specified in [LDAPv3]. 4.1. Update Initiation The protocol is initiated when a supplier sends a StartFramedProtocolRequest extended operation to a consumer to notify it that the following stream of LDAP update operations are to be treated as a unit of update information. The consumer responds to the StartFramedProtocolRequest with a StartFramedProtocolResponse. 4.2. Update Stream After the consumer responds with a StartFramedProtocolResponse extended operation, the supplier sends a stream of LBURPOperationRequest extended operations to the consumer. This stream MAY be sent asynchronously to maximize the efficiency of the transfer. Except in certain circumstances allowed by the protocol to deal with linear and circular dependency issues, the consumer processes each LBURPOperationRequest in the order it was sent by the supplier by applying the LDAP v3 update operations contained within it to the DIT. (The sequence number in each request is utilized to ensure that proper ordering between LBURPOperationRequests is maintained even when the requests are sent asynchronously.) As each LBURPOperationRequest is completed, the consumer sends a LBURPOperationResponse to the supplier indicating the success or failure of the operation. 4.3. Update Termination When the supplier has sent all LBURPOperationRequests, it sends an EndFramedProtocolRequest extended operation to the consumer to terminate the update stream. The consumer responds with an EndFramedProtocolResponse extended operation, and the update is complete. 4.4. Update Styles Two styles of update--full and incremental--are defined. Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 3 LDAP Bulk Update/Replication Protocol March, 2000 Full update creates a completely new set of entries in the target replica; any existing entries in that replica at the start of the StartFramedProtocolRequest operation are removed before the LDAP requests in the replication stream are processed. The only LDAP operation allowed in a full update stream is add. After a server receives and acknowledges a StartFramedProtocolRequest for the LBURPFullUpdateProtocol, the LDAP server MAY choose to not service LDAP requests other than those contained in the update stream for the replica which is being initialized until that update stream is completely processed. Incremental update performs a series of incremental changes to the replica; existing entries in the replica are only affected if explicitly modified in some way by the update operations contained in the update stream. All update operations defined in [LDAPv3]-- add, modify, delete, and moddn--are allowed in the incremental update stream. When a server is processing an incremental update stream, the replica that is being modified MAY choose to not service LDAP requests other than those contained in the update stream until that update stream is completely processed. 4.5. Applicability of Protocol No attempt is made to deal with the issues associated with multiple- master replicas or to maintain state information such as modification times of entries or attribute values in such a way that updates to the same entry on multiple master replicas can be correctly ordered. For this reason convergence of data between all replicas can only be assured in a single-master replication environment. 5. High-level Description of Protocol Flow The following section provides a high-level overview of the replication protocol. Throughout this section, the client or server acting as supplier is indicated by the letter "S", and the server acting as consumer is indicated by the letter "C". The construct "S -> C" indicates that the supplier is sending an LDAPv3 operation to the consumer, and "C -> S" indicates that the consumer is sending an LDAPv3 operation to the supplier. S -> C: LDAP bind operation (identity and credentials used are implementation-defined) C -> S: Bind response S -> C: StartFramedProtocolRequest LDAPv3 extended operation. The parameters are: 1) OID of LBURP incremental or full update Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 4 LDAP Bulk Update/Replication Protocol March, 2000 replication protocol as defined in this document. C -> S: StartFramedProtocolResponse LDAPv3 extended operation. The parameters are: 1) A suggested transactionSize (see section 6.2.1) S -> C: The supplier may send zero or more LBURPOperationRequest LDAPv3 extended operations. The requests MAY be sent asynchronously. The parameters are: 1) A sequence number which specifies the order of the operation with respect to other operations in the replication stream. 2) A list of one or more LDAP v3 update operations. C -> S: The consumer processes each of the LDAP v3 update operations contained within an LBURPOperationRequest. If it was able to successfully complete all of the update operations in the request, the consumer sends an LBURPOperationResponse with a result code of success. If one or more of the LDAP v3 update operations was not completed successfully, the consumer sends an LBURPOperationResponse with a non- success result code and includes a sequence of LDAPResult elements for each of the failed update operations which indicate the reason for failure. S -> C: After all required updates have been sent to the consumer, the supplier sends an EndFramedProtocolRequest LDAPv3 extended operation. The parameters are: 1) A sequence number which is one greater than the sequence number of the last operation in the replication stream. C -> S: The consumer responds by sending an EndFramedProtocolResponse LDAPv3 extended operation. 6. Elements of Protocol The LDAP Bulk Update/Replication protocol works within the framework of the Replication Update Protocol [LDUP RUP]. Unless otherwise Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 5 LDAP Bulk Update/Replication Protocol March, 2000 stated, those elements of protocol taken from the Replication Update Protocol framework are to be used precisely as described there. 6.1. StartFramedProtocolRequest Extended Operation Section 4.1 of [FRAMING] defines the StartFramedProtocolRequest extended operation in terms of the [LDAPv3] ExtendedRequest as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName portion of the StartFramedProtocolRequest must be the OID "2.16.840.1.113719.1.142.100.1". The requestValue of the StartFramedProtocolRequest must be set to the BER-encoding of the following: StartFramedProtocolRequestValue ::= SEQUENCE { framedProtocolOID LDAPOID, framedProtocolPayload OPTIONAL OCTET STRING } 6.1.1. framedProtocolOID The framedProtocolOID is an OID that uniquely identifies the protocol framed by this operation. The framedProtocolOID for the LBURP Incremental Update Protocol is 2.16.840.1.113719.1.142.1.4.1. The framedProtocolOID for the LBURP Full Update Protocol is 2.16.840.1.113719.1.142.1.4.2. 6.1.2. framedProtocolPayload The framedProtocolPayload is an octet string that contains protocol- specific information. For LBURP, there is no framedProtocolPayload element for the StartFramedProtocolRequest extended operation. 6.2. StartFramedProtocolResponse Section 4.2 of [FRAMING] defines the StartFramedProtocolResponse extended operation in terms of the [LDAPv3] ExtendedResponse as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 6 LDAP Bulk Update/Replication Protocol March, 2000 response [11] OCTET STRING OPTIONAL } The responseName of the StartFramedProtocolResponse must be the OID "2.16.840.1.113719.1.142.100.2". For LBURP, the response of a StartFramedProtocolResponse must be set to the BER-encoding of the following: LBURPStartFramedProtocolResponse ::= SEQUENCE { transactionSize INTEGER, } 6.2.1 transactionSize The transactionSize is sent by the consumer to tell the supplier the number of update operations per UpdateOperationList (see section 6.3.2) that it would like the supplier to send. 6.3. LBURPOperationRequest The LBURPOperationRequest extended operation is used to send a set of one or more LDAP v3 update operations from the supplier to the consumer along with sequencing information that enables the consumer to maintain the proper sequencing of among multiple asynchronous requests. An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The responseName of the LBURPOperationRequest must be the OID "2.16.840.1.113719.1.142.100.6". The requestValue of an LBURPOperationRequest extended operation must be set the BER-encoding of the following: LBURPOperationRequestValue ::= SEQUENCE { sequenceNumber INTEGER (1 .. maxInt), updateOperationList UpdateOperationList } 6.3.1. sequenceNumber The sequenceNumber is used to specify the ordering of LBURPOperationRequests. This enables the consumer to know the order in which LBURPOperationRequests must be processed even if it receives them in a sequence different from that in which they were Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 7 LDAP Bulk Update/Replication Protocol March, 2000 sent from the supplier. The supplier MUST set the value of sequenceNumber of the first LBURPOperationRequest to 1, and MUST increment the value of sequenceNumber for each succeeding LBURPOperationRequest. 6.3.2. UpdateOperationList The OpList is a list of one or more standard LDAP update requests and is defined as follows: UpdateOperationList ::= SEQUENCE of CHOICE { addRequest AddRequest, modifyRequest ModifyRequest, delRequest DelRequest, modDNRequest ModifyDNRequest, } AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are standard LDAP update requests as defined in sections 4.6, 4.7, 4.8, and 4.9 of [LDAPv3]. For the LBURP Incremental Update Protocol, all of the choices listed in OpList are valid and can be freely intermixed within an LBURP Incremental Update Protocol replication stream For the LBURP Full Update Protocol, the only valid choice is addRequest. Clients MUST not include any other choice in LBURPOperationRequests sent as part of an LBURP Full Update Protocol replication stream. 6.4. LBURPOperationResponse An LDAPv3 Extended Response is defined in [LDAPv3] as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the LBURPOperationResponse must be the OID "2.16.840.1.113719.1.142.100.7". The response of an LBURPOperationRequest extended operation must be set the BER-encoding of the following: LBURPOperationResponseValue ::= SEQUENCE of OperationResult OperationResult ::= SEQUENCE { Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 8 LDAP Bulk Update/Replication Protocol March, 2000 operationNumber INTEGER, ldapResult LDAPResult } If all of the update operations contained in the LBURPOperationRequest are successfully processed, the resultCode of the LBURPOperationResponse is set to success and no LBURPOperationResponseValue is included in the LBURPOperationResponse. If any of the update operations contained in the LBURPOperationRequest fails, an LBURPOperationResponseValue is included in the LBURPOperationResponse. For each update operation that fails, an OperationResult is included in the LBURPOperationResponseValue. 6.4.1. operationNumber The operationNumber identifies the operation that failed. Operations are numbered beginning at 1. 6.4.2 ldapResult The ldapResult included in the OperationResult is the same ldapResult that would be sent for the update operation that failed if it had failed while being processed as a normal LDAP v3 update operation. 6.5. EndFramedProtocolRequest Section 4.3 of [FRAMING] defines the EndFramedProtocolRequest extended operation in terms of the [LDAPv3] ExtendedRequest as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName of the EndFramedProtocolRequest must be the OID "2.16.840.1.113719.1.142.100.4". For LBURP, the requestValue of the EndFramedProtocolRequest must be set to the BER-encoding of the following: LBURPEndFramedProtocolRequestValue::= SEQUENCE { sequenceNumber INTEGER (1 .. maxInt) } 6.5.1. sequenceNumber Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 9 LDAP Bulk Update/Replication Protocol March, 2000 The value in sequenceNumber is one greater than the last LBURPOperationRequest sequence number in the replication stream. It allows the server to know when it has received all outstanding asynchronous LBURPOperationRequests. 6.6. EndFramedProtcolResponse Section 4.4 of [FRAMING] defines the EndFramedProtocolResponse extended operation in terms of the [LDAPv3] ExtendedResponse as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS of LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } The responseName of the EndFramedProtocolResponse must be the OID "2.16.840.1.113719.1.142.100.5". For LBURP, there is no response element for the EndFramedProtocolResponse extended operation. 7. Semantics of Full and Incremental Update Protocols 7.1. Semantics Common to Both Full and Incremental Update Protocols Since both the full and incremental update protocols use sequences of standard LDAP v3 operations to transmit update information, no attempt is made by the protocol to include the information needed to support full multi-master replication as defined by [LDUP RUP]. Although entries and their associated attributes and attribute values can be synchronized using this protocol, no CSNs are included in the update stream; updates made using this replication protocol are treated the same as other LDAP operations wherein they are deemed to occur at the present. Operational attributes such as modifiersTimeStamp MAY be included in the replication stream, and if they are, they SHOULD be put into the entry. The LBURPOperationRequests that form the replication stream MAY be sent asynchronously by the supplier to the consumer. This means that the supplier need not wait for a LBURPOperationResponse from one LBURPOperationRequest before sending the next. The LBURPOperationRequests in the replication stream, plus the initial state of entries in the consumer replica in the case of incremental update, collectively represent the desired final state of the consumer replica. The consumer server may take any action required to efficiently achieve this desired final state of the replica. Examples of such actions include reordering LDAP requests to ensure that linear dependencies within the replication stream are Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 10 LDAP Bulk Update/Replication Protocol March, 2000 correctly ordered, breaking an LDAP modification request into two or more separate modification requests to adequately resolve a circular dependency within the replication stream, and aggregating LDAP update operations to process them more efficiently. When taking actions of this sort, the server MUST NOT reorder LDAP requests in such a way that the desired final state is different from that which would have been achieved before the action was taken. While a consumer server is processing a an LBURP update stream, the it MAY choose to not service LDAP requests for the replica involved in the replication operation other than those contained in the replication stream including LDAP requests on other connections. This requirement is designed to allow implementers the freedom to implement highly-efficient methods of handling the replication stream without being constrained by the need to maintain a live, working DIT database while doing so. 7.2. Semantics of the Full Replication Protocol Full replication creates a completely new set of entries in that replica; any existing entries in that replica at the start of the replication operation are removed before the LDAP requests in the replication stream are processed. The only LDAP operation allowed in a full update stream is add. Clients MUST NOT send any other type of update operation in the full update stream. If any other LDAP operation is received as part of the update stream, the server MUST return unwillingToPerform as the response for the operation. If the full update sequence fails for some reason (e.g. a connection is abruptly broken in the middle of an otherwise-successful update sequence) the server MUST remove any entries created during the update sequence, thereby leaving the replica in a known state. 7.3. Semantics of the Incremental Replication Protocol Incremental replication performs a series of incremental changes to the replica; existing entries in the replica are only affected if explicitly modified in some way by the update operations contained in the replication stream. All LDAP v3 update operations--add, modify, delete, and moddn--are allowed in the incremental replication stream. If a non-update operation is received as part of the replication stream, the server MUST return unwillingToPerform as the response for the operation. 8. Notes To Implementers Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 11 LDAP Bulk Update/Replication Protocol March, 2000 It is RECOMMENDED that, if possible, the consumer LDAP server refer non-replication requests for the replica being updated to another server containing that replica during the time that consumer LDAP server has the replica off-line for replication. Implementations MAY choose to perform the operations in the replication stream with special permissions to improve performance. 9. Security Considerations Implementations should ensure that a supplier making a Bulk Update/Replication request is bound with appropriate permissions. There is a potential for loss of data, especially with the full update protocol, which removes all entries in a replica as part of its operation. Second, forcing the removal of all entries in a replica may consume large amounts of server resources. Third, unlike other replication protocols, no existing replication agreement between supplier and consumer is required. These risks increase if the consumer server also processes the replication stream with special permissions to improve performance. For these reasons, implementers should carefully consider which identities or permissions are required to perform Bulk Update/Replication Protocol operations and take steps to ensure that only connections bound with appropriate permissions are allowed to perform them. The data contained in the replication stream may contain passwords and other sensitive data. Care should be taken to properly safeguard this information while in transit between supplier and consumer. 10. Document Revision History 10.1. draft-rharrison-lburp-00.txt Initial Draft 10.2. draft-rharrison-lburp-01.txt Adjusted LBURP protocol to use extended requests for all operations. LDAP update operations are now encapsulated within the LBURP Operation Request for two reasons: (1) To allow the inclusion of operation ordering information. This allows LDAP servers to maintain the proper ordering of updates even in cases where multi-threaded stacks present update operations to the server out-of-sequence. (2) To allow multiple update operations to be sent from client to server in a single request. This was a natural evolution of the changes made for (1) and allows the protocol to make more efficient use of network bandwidth, Converted references to LDUP extended operations to use a new LDAP Framed Operations Protocol. Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 12 LDAP Bulk Update/Replication Protocol March, 2000 Specified OIDs used for the protocol and extended operations. Changed requirement that a server "MUST NOT" service non-LBURP requests during a full update to a "MAY choose to not" service non- LBURP requests during a full update. This gives implementers the option to do what is needed without imposing a requirement that may not be needed by some implementations. 11. References [FRAMING] Stokes, Ellen, and Gordon Good, “Extended Operations for Framing LDAP Operations”, UNPUBLISHED INTERNET-DRAFT: ldup- framing.txt. [LDAPv3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [LDIF] Gordon Good, "LDAP Data Interchange Format (LDIF)", INTERNET- DRAFT: draft-good-ldap-ldif-04.txt, 22 June 1999. [ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate Requirement Levels". RFC 2119. 12. Author's Addresses Roger Harrison Novell, Inc. 122 E. 1700 S. Provo, UT 84606 +1 801 861 2642 roger_harrison@novell.com Jim Sermersheim Novell, Inc. 122 E. 1700 S. Provo, UT 84606 +1 801 861 3088 jimse@novell.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 13 LDAP Bulk Update/Replication Protocol March, 2000 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Individual Submission - Expires September 10, 2000 Harrison & Sermersheim 14 --=_EAB3109D.ACCDD32B-- From owner-ietf-ldup@mail.imc.org Thu Mar 16 12:09:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23004 for ; Thu, 16 Mar 2000 12:09:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13288 for ietf-ldup-bks; Thu, 16 Mar 2000 08:41:04 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13282 for ; Thu, 16 Mar 2000 08:40:53 -0800 (PST) Received: from NSYRACUS ([10.27.5.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11704; Thu, 16 Mar 2000 11:42:10 -0500 (EST) Date: Thu, 16 Mar 2000 11:45:03 -0500 (Eastern Standard Time) From: Natalia Syracuse To: Ed Reed cc: internet-drafts@ietf.org, ietf-ldup@imc.org Subject: Re: draft-ietf-ldup-infomod-03.txt In-Reply-To: Message-ID: X-X-Sender: nsyracus@odin.ietf.org 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: It will be ver01 (I can'skip the versions, our database doesn't allow us to do it). Natalia Syracuse On Fri, 10 Mar 2000, Ed Reed wrote: > Please publish the attached internet draft. It replaces draft-ietf-ldup-infomod-00.txt, but you havent' gotten all the interrum versions. It is the product of the LDUP working group. > > Abstract: > > This interrum version of the LDUP Information Model is intended to provide the developer community with updates to the design, and a snapshot of the work in progress. Work is currently underway to ensure that this document is fully alligned with the LDUP Architectural Model document. > > [LDUP Model] describes the architectural approach to replication of > LDAP directory contents. This document describes the information > model and schema elements which support LDAP Replication Services > which conform to [LDUP Model]. > > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.OnCallDBA.COM > > From owner-ietf-ldup@mail.imc.org Thu Mar 16 16:49:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04679 for ; Thu, 16 Mar 2000 16:49:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA19443 for ietf-ldup-bks; Thu, 16 Mar 2000 13:18:23 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19438 for ; Thu, 16 Mar 2000 13:18:21 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23516; Thu, 16 Mar 2000 16:19:41 -0500 (EST) Message-Id: <200003162119.QAA23516@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-model-03.txt Date: Thu, 16 Mar 2000 16:19:41 -0500 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 Replication Architecture Author(s) : J. Merrells, E. Reed, U. Srinivasan Filename : draft-ietf-ldup-model-03.txt Pages : 37 Date : 15-Mar-00 This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-03.txt 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-model-03.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-model-03.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: <20000315132845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-model-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132845.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 17 08:54:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05170 for ; Fri, 17 Mar 2000 08:54:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA08968 for ietf-ldup-bks; Fri, 17 Mar 2000 05:21:40 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08964 for ; Fri, 17 Mar 2000 05:21:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22191; Fri, 17 Mar 2000 08:23:02 -0500 (EST) Message-Id: <200003171323.IAA22191@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-infomod-01.txt Date: Fri, 17 Mar 2000 08:23:01 -0500 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 : LDUP Replication Information Model Author(s) : E. Reed Filename : draft-ietf-ldup-infomod-01.txt Pages : 18 Date : 16-Mar-00 [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (ie, subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-01.txt 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-infomod-01.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-infomod-01.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: <20000316144620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-infomod-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-infomod-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Sat Mar 18 14:02:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17889 for ; Sat, 18 Mar 2000 14:02:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18489 for ietf-ldup-bks; Sat, 18 Mar 2000 10:24:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18485 for ; Sat, 18 Mar 2000 10:24:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03659; Sat, 18 Mar 2000 13:26:21 -0500 (EST) Message-Id: <200003181826.NAA03659@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-framing-00.txt Date: Sat, 18 Mar 2000 13:26:21 -0500 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 : Extended Operations for Framing LDAP Operations Author(s) : E. Stokes, R. Harrison, G. Good Filename : draft-ietf-ldup-framing-00.txt Pages : 6 Date : 17-Mar-00 Certain types of LDAP applications can benefit from the ability to specify the beginning and end of a related group of operations. For example, the LDUP multimaster update protocol [ARCHITECTURE] requires that two servers agree to begin a session to transfer pending replication updates. This document provides a framework for constructing protocols that feature a framed set of related operations. It defines a pair of LDAPv3 extended operations that provide begin-end framing, and a pair of extended operations used to respond the begin-end framing operations. The nature of the actual LDAP operations carried inside these framing operations is not specified in this document. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. Certain terms used in this document are defined in the document 'LDAP Replication Architecture' [ARCHITECTURE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-00.txt 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-framing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-framing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000317103227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-framing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-framing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000317103227.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Mar 29 22:20:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28711 for ; Wed, 29 Mar 2000 22:20:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA15896 for ietf-ldup-bks; Wed, 29 Mar 2000 18:40:15 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15890 for ; Wed, 29 Mar 2000 18:40:15 -0800 (PST) Received: from threadgill.austin.innosoft.com ([207.8.108.5]) by INNOSOFT.COM (PMDF V6.0-24 #9441) with ESMTP id <01JNM5P2KVWY9KMZ1J@INNOSOFT.COM> for ietf-ldup@imc.org; Wed, 29 Mar 2000 18:41:37 -0800 (PST) Received: from threadgill.austin.innosoft.com (threadgill.austin.innosoft.com [207.8.108.5]) by austin.innosoft.com (PMDF V5.2-32 #41296) with SMTP id <0FS700F1VRMKWP@austin.innosoft.com>; Wed, 29 Mar 2000 20:44:44 -0600 (CST) Date: Wed, 29 Mar 2000 20:44:44 -0600 From: Mark Wahl Subject: Re: LDUP management operations In-reply-to: "Your message of Mon, 06 Mar 2000 20:33:42 EST." <38C45C76.80DCF00D@att.com> To: Chris Apple Cc: Jim Sermersheim , ietf-ldup@imc.org Message-id: <20890.954384284@threadgill.austin.innosoft.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have only about 13 pages done of the replica management and do not have the termination cases worked out. I haven't had much time to work on it since the last meeting. If Jim would like to continue on this, that would be helpful. Mark Wahl, Directory Product Architect Innosoft International, Inc. From owner-ietf-ldup@mail.imc.org Thu Mar 30 00:40:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01621 for ; Thu, 30 Mar 2000 00:40:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24283 for ietf-ldup-bks; Wed, 29 Mar 2000 21:04:38 -0800 (PST) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24278 for ; Wed, 29 Mar 2000 21:04:37 -0800 (PST) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12aXAg-00078E-00 for ietf-ldup@imc.org; Wed, 29 Mar 2000 22:07:06 -0700 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Wed, 29 Mar 2000 22:06:32 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 29 Mar 2000 22:01:34 -0700 From: "Ed Reed" To: Cc: Subject: Fwd: RE: UUID Ref. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_9AC34DC8.2D4C201D" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_9AC34DC8.2D4C201D Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks -=20 The question about UUID definitions seems to be resolved....we'll refer to = the OpenGroup's RPC specification. See attached reference from Chris = Harding, and the detailed description of the DCE UUID format at http://www.= opengroup.org/onlinepubs/009629399/apdxa.htm=20 Okay? Thanks, Chris Ed --=_9AC34DC8.2D4C201D Content-Type: message/rfc822 MIME-Version: 1.0 --=_9AC34DC8.2D4C201D-- From owner-ietf-ldup@mail.imc.org Thu Mar 30 02:38:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13683 for ; Thu, 30 Mar 2000 02:38:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA29064 for ietf-ldup-bks; Wed, 29 Mar 2000 23:05:23 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA29060 for ; Wed, 29 Mar 2000 23:05:22 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 30 Mar 2000 00:05:35 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 30 Mar 2000 00:05:20 -0700 From: "Haripriya S" To: Subject: Replication between replicas with potentially differing schemas Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA29061 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, 1. Is there any ongoing work on standards to replicate between replicas having differing schema definitions, mapping schema definitions for this purpose? 2. I would also like to know if there is any LDAP working group involved in standards for transaction-like (immediately and atomically synchronized ) operations in LDAP directories. Thanks and Regards, Haripriya From owner-ietf-ldup@mail.imc.org Thu Mar 30 03:16:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14011 for ; Thu, 30 Mar 2000 03:16:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA01134 for ietf-ldup-bks; Wed, 29 Mar 2000 23:45:13 -0800 (PST) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01129 for ; Wed, 29 Mar 2000 23:45:12 -0800 (PST) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12aZg7-0000bn-00 for ietf-ldup@imc.org; Thu, 30 Mar 2000 00:47:43 -0700 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Thu, 30 Mar 2000 00:47:07 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 30 Mar 2000 00:46:03 -0700 From: "Ed Reed" To: , Subject: LDAP Subentry and naming Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA01130 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit During the LDUP discussion of the LDAP Subentry draft the matter of naming attributes came up again, and we need to settle what the draft needs to say. Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory. Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN. The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry. Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above. There might be several possible solutions: 1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named. 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users; 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. Option 1 takes ldapSubEntry further and further away from the X.500 definition. That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted. Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room. At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem? Option 3, it seems to me, should be our fall back if concensus can't be reached quickly - by the end of April, for instance. LDUP doesn't particularly care. That would mean leaving it as it is (I think). Please reply by 23 April with your feelings, if you care. If not, stay tuned to see what develops. I plan to submit this for last call by the end of April, 2000. Regards, Ed Reed From owner-ietf-ldup@mail.imc.org Thu Mar 30 03:26:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14130 for ; Thu, 30 Mar 2000 03:26:20 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA01848 for ietf-ldup-bks; Wed, 29 Mar 2000 23:53:58 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01842 for ; Wed, 29 Mar 2000 23:53:56 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21702; Wed, 29 Mar 2000 23:56:11 -0800 (PST) Received: from swanaba.east (swanaba.East.Sun.COM [129.148.162.54]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA21719; Thu, 30 Mar 2000 02:56:11 -0500 (EST) Received: from notebook (swantty.East.Sun.COM [129.148.162.52]) by swanaba.east (8.8.8+Sun/8.8.8) with SMTP id CAA24652; Thu, 30 Mar 2000 02:55:26 -0500 (EST) Message-ID: <009c01bf9a1d$6c08ac20$d4c0d0a9@aus.sun.com> From: "Anil SRIVASTAVA" To: "Ed Reed" , , References: Subject: Re: LDAP Subentry and naming Date: Wed, 29 Mar 2000 23:56:00 -0800 Organization: Sun | Netscape Alliance (http://www.iPlanet.com) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Disposition-Notification-To: "Anil SRIVASTAVA" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would vote for option 1. Not too hung up on the name and ldapSE sounds as good as any other. _________ Anil Srivastava anil.srivastava@Eng.Sun.COM ----- Original Message ----- From: "Ed Reed" To: ; Sent: Wednesday, March 29, 2000 11:46 PM Subject: LDAP Subentry and naming During the LDUP discussion of the LDAP Subentry draft the matter of naming attributes came up again, and we need to settle what the draft needs to say. Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory. Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN. The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry. Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above. There might be several possible solutions: 1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named. 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users; 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. Option 1 takes ldapSubEntry further and further away from the X.500 definition. That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted. Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room. At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem? Option 3, it seems to me, should be our fall back if concensus can't be reached quickly - by the end of April, for instance. LDUP doesn't particularly care. That would mean leaving it as it is (I think). Please reply by 23 April with your feelings, if you care. If not, stay tuned to see what develops. I plan to submit this for last call by the end of April, 2000. Regards, Ed Reed From owner-ietf-ldup@mail.imc.org Thu Mar 30 03:43:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14305 for ; Thu, 30 Mar 2000 03:43:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA03102 for ietf-ldup-bks; Thu, 30 Mar 2000 00:07:52 -0800 (PST) Received: from etrn.xmission.com (root@etrn.xmission.com [198.60.22.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03097 for ; Thu, 30 Mar 2000 00:07:51 -0800 (PST) Received: from [166.70.104.61] (helo=mail.oncalldba.com) by etrn.xmission.com with smtp (Exim 2.12 #1) id 12aa22-0000oI-00 for ietf-ldup@imc.org; Thu, 30 Mar 2000 01:10:22 -0700 Received: from RMINC_DOM-Message_Server by mail.oncalldba.com with Novell_GroupWise; Thu, 30 Mar 2000 01:09:46 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 30 Mar 2000 01:08:56 -0700 From: "Ed Reed" To: , Cc: "Ellen Stokes" , Subject: Re: Replication between replicas with potentially differingschemas Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA03099 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 1) we decided to leave this out of scope for LDUP. I'm not aware of any other ietf group working on the issue for directories, at least; 2) LDAPEXT has considered this, and may work on it in the future - suggest you contact Ellen Stokes (IBM) and Dave Boreham (Netscape) to express your interest. >>> "Haripriya S" 3/30/00 4:35:20 PM >>> Hi, 1. Is there any ongoing work on standards to replicate between replicas having differing schema definitions, mapping schema definitions for this purpose? 2. I would also like to know if there is any LDAP working group involved in standards for transaction-like (immediately and atomically synchronized ) operations in LDAP directories. Thanks and Regards, Haripriya From owner-ietf-ldup@mail.imc.org Thu Mar 30 11:47:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17714 for ; Thu, 30 Mar 2000 11:47:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA21882 for ietf-ldup-bks; Thu, 30 Mar 2000 08:13:41 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21878 for ; Thu, 30 Mar 2000 08:13:40 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA27396 for ; Thu, 30 Mar 2000 08:13:01 -0800 (PST) Received: from netscape.com ([198.93.95.121]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FS8T6500.G6E; Thu, 30 Mar 2000 08:15:41 -0800 Message-ID: <38E37DF8.EEA7658@netscape.com> Date: Thu, 30 Mar 2000 11:16:56 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ed Reed CC: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: LDAP Subentry and naming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On the choice of a naming attribute for ldapSubEntry objects, I think the safest choice is to define a new attribute type and say that people MAY use it for naming. I would call it "ldapSubEntryName" and still leave it as an optional ("MAY") type in the objectclass definition in case someone wants to use a different attribute for naming. So... I am basically endorsing option 1 of the three you proposed. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From owner-ietf-ldup@mail.imc.org Fri Mar 31 01:32:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02022 for ; Fri, 31 Mar 2000 01:32:40 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA13159 for ietf-ldup-bks; Thu, 30 Mar 2000 21:57:39 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA13147 for ; Thu, 30 Mar 2000 21:57:33 -0800 (PST) Received: (qmail 24443 invoked from network); 31 Mar 2000 06:00:07 -0000 Received: from softdnserror (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 31 Mar 2000 06:00:07 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" , , Subject: RE: LDAP Subentry and naming Date: Fri, 31 Mar 2000 16:02:04 +1000 Message-ID: <000601bf9ad6$a4091240$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, There's a fourth option which is to keep CN as the naming attribute but recommend a convention for naming subentries that makes a name clash very unlikely. The convention could be as simple as "the CN of subentries should begin with the text `subentry:' ". I've been habitually using CN=Subschema for the subschema subentry for years and it hasn't been a problem yet so I'm wondering how real a problem this is. Mysterious name clashes are nothing new either since a user could easily (and perhaps more likely) enter a name that clashes with an existing entry that is invisible due to access controls. Any software automatically generating subentries ought to have a backoff strategy trying alternative names until one works, whatever the naming attribute is, so I don't see a problem there. I don't like the idea of leaving the choice of naming attribute to the developers for such an important component of directory operation. All the necessary definitions for LDUP subentries should be widely known. Regards, Steven -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Ed Reed Sent: Thursday, 30 March 2000 17:46 To: ietf-ldup@imc.org; ietf-ldapext@netscape.com Subject: LDAP Subentry and naming During the LDUP discussion of the LDAP Subentry draft the matter of naming attributes came up again, and we need to settle what the draft needs to say. Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory. Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN. The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry. Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above. There might be several possible solutions: 1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named. 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users; 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. Option 1 takes ldapSubEntry further and further away from the X.500 definition. That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted. Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room. At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem? Option 3, it seems to me, should be our fall back if concensus can't be reached quickly - by the end of April, for instance. LDUP doesn't particularly care. That would mean leaving it as it is (I think). Please reply by 23 April with your feelings, if you care. If not, stay tuned to see what develops. I plan to submit this for last call by the end of April, 2000. Regards, Ed Reed