From owner-ietf-ldup@mail.imc.org Mon Oct 6 17:05:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22592 for ; Mon, 6 Oct 2003 17:05:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96KrVKP071438 for ; Mon, 6 Oct 2003 13:53:31 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h96KrV1B071437 for ietf-ldup-bks; Mon, 6 Oct 2003 13:53:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h96KrUKP071431 for ; Mon, 6 Oct 2003 13:53:30 -0700 (PDT) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A6cMB-0005tJ-5G; Mon, 06 Oct 2003 16:53:27 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'LDAP Client Update Protocol' to Proposed Standard Message-Id: Date: Mon, 06 Oct 2003 16:53:27 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved following document: - 'LDAP Client Update Protocol' as a Proposed Standard This document is the product of the LDAP Duplication/Replication/Update Protocols Working Group. The IESG contact persons are Ted Hardie and Ned Freed. Technical Summary The LCUP protocol allows LDAP clients to synchronize with the content stored by LDAP servers; it does not address server to server synchronization. It has three main proposed use cases: limited clients that need to maintain read-only copies of directory data for use while off-line; applications synchronizing local data with multiple data stores to create a different view of the data (e.g. a meta directory); and clients which perform automated tasks based on directory information triggers (e.g. a client that creates new mailboxes when a new directory entry is created). Working Group Summary The group achieved rough consensus after significant debate. A minority view that this protocol represented the wrong engineering choice in the face of common implementations was discussed extensively on the mailing list and the issues raised again during last call. The key point of contention was how the balance between server state and on-the-wire traffic should be struck. The draft's applicability statement indicates that some level of server state would be required to avoid full synchronization (and its implied cost in traffic and processing), and there was debate over the relative costs for current and furture implementations. After a focused period of discussion, the working group came to rough consensus that the protocol contained sufficient mechanisms to handle cases where incremental update was sub-optimal and the document clear enough in its applicability statement to prevent misunderstanding. Protocol Quality Ted Hardie reviewed this document for the IESG. From subs-reminder@imc.org Mon Oct 6 23:23:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03694 for ; Mon, 6 Oct 2003 23:23:06 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h973NCKP002712 for ; Mon, 6 Oct 2003 20:23:12 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h973NCjD002711; Mon, 6 Oct 2003 20:23:12 -0700 (PDT) Date: Mon, 6 Oct 2003 20:23:12 -0700 (PDT) Message-Id: <200310070323.h973NCjD002711@above.proper.com> To: ldup-archive@ietf.org Subject: [[309596301]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From subs-reminder@imc.org Mon Oct 6 23:25:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03733 for ; Mon, 6 Oct 2003 23:25:23 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h973PSKP002964 for ; Mon, 6 Oct 2003 20:25:28 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h973PSef002963; Mon, 6 Oct 2003 20:25:28 -0700 (PDT) Date: Mon, 6 Oct 2003 20:25:28 -0700 (PDT) Message-Id: <200310070325.h973PSef002963@above.proper.com> To: ldup-archive@ietf.org Subject: [[849452729]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ldup@mail.imc.org Mon Oct 13 14:01:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17777 for ; Mon, 13 Oct 2003 14:01:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHoOI7041630 for ; Mon, 13 Oct 2003 10:50:24 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DHoOck041629 for ietf-ldup-bks; Mon, 13 Oct 2003 10:50:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [216.98.200.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DHoMI7041611 for ; Mon, 13 Oct 2003 10:50:23 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (pcp086396pcs.audubn01.nj.comcast.net [68.44.129.64]) by echt.caledonia.net; Mon, 13 Oct 2003 11:49:32 -0600 Reply-To: From: "Chris Apple" To: Subject: LDUP WG Meeting Request Date: Mon, 13 Oct 2003 13:49:20 -0400 Organization: DSI-Consulting, Inc. Message-ID: <006b01c391b2$5884f2e0$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit We have requested a WG Meeting Slot in Minneapolis. So far the Meeting Agenda hasn't been updated since October 1. I will post the meeting slot information as soon as I notice it on the web page. But if you have a need to plan travel around the day of the meeting, I recommend that you keep an eye on the meeting agenda page for LDUP's slot to appear. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Sat Oct 18 14:14:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04187 for ; Sat, 18 Oct 2003 14:14:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9II8SI7026265 for ; Sat, 18 Oct 2003 11:08:28 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9II8SN4026264 for ietf-ldup-bks; Sat, 18 Oct 2003 11:08:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from cosium01.intelliden.net (cosium01.intelliden.net [12.41.186.248]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9II8RI7026259 for ; Sat, 18 Oct 2003 11:08:27 -0700 (PDT) (envelope-from John.Strassner@intelliden.com) Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Sat, 18 Oct 2003 12:08:27 -0600 Message-ID: From: John Strassner To: "''Ietf-Ldup@Imc. Org' (ietf-ldup@imc.org)'" Subject: Prelim Schedule for Minneapolis Date: Sat, 18 Oct 2003 12:08:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C395A2.D4F8EDB0" Sender: owner-ietf-ldup@mail.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_01C395A2.D4F8EDB0 Content-Type: text/plain This is what has been posted so far: TUESDAY, November 11, 2003 ... 1130-1300 Break 1300-1400 Afternoon Sessions I APP ldapbis LDAP (v3) Revsion WG Open Trading Protocol WG INT send Securing Neighbor Discovery WG OPS dnsop Domain Name System Operations WG OPS ipcdn IP over Cable Data Network WG RTG pim Protocol Independent Multicast WG SEC enroll Credential and Provisioning BOF TSV enum Telephone Number Mapping WG 1415-1515 Afternoon Sessions II APP ldup LDAP Replication/Duplication/Update Protocols WG INT magma Multicast & Anycast Group Membership WG OPS pana Protocol for Carrying Authentication for Network Access WG OPS multi6 Site Multihoming in IPv6 WG SEC krb-wg Kerberos WG TSV alias Access Lind Intermediaries Assisting Services BOF regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com ------_=_NextPart_001_01C395A2.D4F8EDB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Prelim Schedule for Minneapolis

This is what has = been posted so far:

TUESDAY, = November 11, 2003

...

1130-1300 = Break

1300-1400 = Afternoon Sessions I

APP       ldapbis  LDAP (v3) = Revsion WG Open Trading Protocol WG

INT       = send     Securing Neighbor Discovery = WG

OPS       dnsop    = Domain Name System Operations WG

OPS       ipcdn    IP = over Cable Data Network = WG

RTG       = pim      Protocol Independent Multicast = WG

SEC       enroll   = Credential and Provisioning BOF

TSV       = enum     Telephone Number Mapping WG

1415-1515 = Afternoon Sessions II

APP       = ldup     LDAP Replication/Duplication/Update = Protocols = WG

INT       magma    = Multicast & Anycast Group Membership WG

OPS       = pana     Protocol for Carrying Authentication for = Network Access WG

OPS       multi6   Site = Multihoming in IPv6 WG

SEC       krb-wg   = Kerberos WG

TSV       alias    = Access Lind Intermediaries = Assisting Services BOF


regards,
John

John C. = Strassner

Chief Strategy = Officer

Intelliden = Inc.

90 South Cascade = Avenue

Colorado = Springs, CO  80906  USA

phone:  = +1.719.785.0648

  = fax:     +1.719.785.0644

email:    = john.strassner@intelliden.com

------_=_NextPart_001_01C395A2.D4F8EDB0-- From owner-ietf-ldup@mail.imc.org Sun Oct 19 22:00:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26338 for ; Sun, 19 Oct 2003 22:00:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9K1qcI7003360 for ; Sun, 19 Oct 2003 18:52:38 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9K1qcTD003359 for ietf-ldup-bks; Sun, 19 Oct 2003 18:52:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9K1qaI7003284 for ; Sun, 19 Oct 2003 18:52:36 -0700 (PDT) (envelope-from Uppili.srinivasan@oracle.com) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9K1WrWs029286; Sun, 19 Oct 2003 18:32:53 -0700 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h9K1Wq707371; Sun, 19 Oct 2003 19:32:52 -0600 (MDT) Received: from acer (whq4op3u33-ppp-sfc1-61.us.oracle.com [144.25.200.147]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id h9K1WO706942; Sun, 19 Oct 2003 19:32:24 -0600 (MDT) Message-ID: <003201c396ab$5b4c31c0$93c81990@acer> From: "Uppili.Srinivasan" To: Cc: , , , , Date: Sun, 19 Oct 2003 18:41:47 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002E_01C39670.A6BE51A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C39670.A6BE51A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002F_01C39670.A6BE51A0" ------=_NextPart_001_002F_01C39670.A6BE51A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Drafts Editor - Please publish the attached as draft-ietf-ldup-model-09.txt. LDUPers - Attached is the latest version of the LDUP Profiles draft. I have made = the changes that have been suggested by various reviewers. Most notably, = thanks to Jerry Maziarsky for a detailed review and comments to address = areas ambiguity. =20 Per the plan stated in Vienna, I would like to submit this for WG last = call. The following edits have been made in this version of the draft: (1) The relationships between different deployment configurations = (single vs multi-master) and consistency models (synchronous vs = asynchronous) are clarified.=20 (2) The architecture spells out that the DITs of replicating directories = need not be symmetric. Only the areas under replication need be. =20 (3) A section is added to highlight availability considerations when = nodes are added, deleted or upgraded without adversely affecting total = system up-time, since one of the objectives of replication is high = availability.=20 (4) The scope of LDUP is clarified as not for only among homogenous = DSAs (same vendor) but also for heterogeneous DSAs (multi-vendor). Thanks, Uppili Srinivasan ------=_NextPart_001_002F_01C39670.A6BE51A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Drafts Editor = -

Please=20 publish the attached as draft-ietf-ldup-model-09.txt.

LDUPers=20 -

Attached is the latest version of the LDUP Profiles = draft.  I have=20 made the changes that have been suggested by various reviewers. Most = notably,=20 thanks to Jerry Maziarsky for a detailed review and comments to address = areas=20 ambiguity.  

Per the plan stated in Vienna, I would = like to=20 submit this for WG last call.

The following edits have been made = in this=20 version of the draft:

(1) The relationships between different = deployment=20 configurations (single vs multi-master) and consistency models = (synchronous vs=20 asynchronous) are clarified.

(2) The architecture spells out = that the=20 DITs of replicating directories need not be symmetric.  Only the = areas=20 under replication need be. 

(3) A section is added to = highlight=20 availability considerations when nodes are added, deleted or upgraded = without=20 adversely affecting total system up-time, since one of the objectives of = replication is high availability.

(4) The scope of LDUP is = clarified as=20 not for only among homogenous  DSAs (same vendor) but also for=20 heterogeneous DSAs (multi-vendor).

Thanks,
Uppili=20 Srinivasan ------=_NextPart_001_002F_01C39670.A6BE51A0-- ------=_NextPart_000_002E_01C39670.A6BE51A0 Content-Type: text/plain; name="draft-ietf-ldup-model-09.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ldup-model-09.txt" Content-Transfer-Encoding: quoted-printable =20 Internet Draft John Merrells Document: draft-ietf-ldup-model-09.txt Sleepy Cat Software, Inc Expires: March 2004 Uppili Srinivasan Oracle Corportation Ed Reed Novell Corporation October = 2003 =20 =20 LDAP Replication Architecture=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/1id-abstracts.html=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 =20 This draft, file name draft-ietf-ldup-model-08.txt, is intended to=20 be become a Proposed Standard RFC, to be published by the IETF=20 Working Group LDUP. Distribution of this document is unlimited.=20 Comments should be sent to the LDUP Replication mailing list=20 or to the authors.=20 =20 This Internet-Draft expires September 2003=20 =20 1 Abstract=20 =20 This architectural document outlines a suite of schema and protocol=20 extensions to LDAPv3 that enables the robust, reliable, server-to- server exchange of directory content and changes.=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC 2119=20 [RFC2119]. The sections below reiterate these definitions and=20 include some additional ones.=20 =20 =0C LDAP Replication Architecture Model October 2003 =20 =20 =20 2 Table of Contents=20 Status of this Memo.................................................1=20 1 Abstract ........................................................1=20 2 Table of Contents ...............................................2=20 3 Introduction ....................................................3=20 3.1 Scope 3=20 3.2 Document Objectives 4=20 3.3 Document Non-Objectives 5=20 3.4 Existing Implementations 5=20 3.5 Terms and Definitions 6=20 3.6 Deployment Topologies and Associated Consistency Models 7=20 3.7 LDAP Constraints 8=20 4 Replication Environment .........................................9=20 4.1 Primary Replica 9=20 4.2 Master Replica 10=20 4.3 Read-Only Replica 10=20 4.4 Fractional Replicas 10=20 5 Information Model ..............................................10=20 5.1 Sub-Entries 11=20 5.2 Glue Entries 11=20 5.3 Unique Identifiers 11=20 5.4 Change Sequence Number 11=20 5.5 Entries, Semantics and Relationships 13=20 5.6 Root DSE Attributes 13=20 5.7 Replication Context Auxiliary Object Class and Entries 14=20 5.8 Replica Object Class and Entries 14=20 5.9 Lost and Found Entry 14=20 5.10 Replication Agreement Object Class and Entries 14=20 6 Replication of Directory Administrative Policy Information .....16=20 6.1 Schema Replication 16=20 7 Change Representation and Update Resolution ....................16=20 7.1 Entry Creation and Deletion 17=20 7.2 Attribute Creation and Deletion 17=20 7.3 Attribute Value Changes 17=20 7.4 Update Inconsistency 18=20 8 LDUP Update Transfer Protocol Framework ........................18=20 8.1 Replication Session Initiation 18=20 8.2 Start Replication Session 19=20 8.3 Update Transfer 19=20 8.4 End Replication Session 20=20 8.5 Major States of Replicas 20=20 8.6 Integrity & Confidentiality 21=20 9 LDUP Update Protocols ..........................................21=20 9.1 Replication Updates and Update Primitives 21=20 9.2 Fractional Updates 22 10 = LDUP Full Update Transfer Protocol .............................22=20 10.1 Full Update Transfer 22=20 10.2 Replication Update Generation 22=20 10.3 Replication Update Consumption 22=20 =20 =0C LDAP Replication Architecture Model October = 2003 =20 10.4 Full Update, End Replication Session 22=20 10.5 Interrupted Transmission 22=20 11 LDUP Incremental Update Transfer Protocol ......................23=20 11.1 Update Vector 23=20 11.2 Supplier Initiated, Incremental Update, Start Replication=20 Session 24 = 11.3 Replication Update Generation 24=20 11.4 Replication Update Consumption 25=20 11.5 Update Resolution Procedures 25=20 11.6 Incremental Update, End Replication Session 27=20 11.7 Interrupted Transmission 27=20 12 Purging State Information ......................................27=20 12.1 Purge Vector 27=20 12.2 Purging Deleted Entries, Attributes, and Attribute Values 28=20 13 Replication Configuration and Management .......................28=20 14 Availability Considerations ....................................30=20 15 Security Considerations ........................................30=20 15.1 Audit Capabilities 31=20 16 Acknowledgements ...............................................31=20 17 References .....................................................31=20 18 Authors' Address ...............................................34=20 19 Appendix A _ LDAP Constraints ..................................34=20 19.1 LDAP Constraints Clauses 34=20 19.2 LDAP Data Model Constraints 35=20 19.3 LDAP Operation Behaviour Constraints 36=20 19.4 New LDAP Constraints 37=20 =20 3 Introduction=20 =20 3.1 Scope=20 =20 This architectural document provides an outline of an LDAP based=20 replication scheme. Further detailed design documents will draw=20 guidance from here.=20 =20 The design proceeds from prior work in the industry, including=20 concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory=20 Information Shadowing Protocol (DISP) [X525], experience with widely=20 deployed distributed directories in network operating systems,=20 electronic mail address books, and other database technologies. The=20 emphasis of the design is on:=20 =20 a) Simplicity of operation.=20 b) Flexibility of configuration.=20 c) Manageability of replica operations among mixed heterogeneous=20 vendor LDAP servers under common administration.=20 =20 d) Security of content and configuration information when LDAP=20 servers from more than one administrative authority are=20 interconnected.=20 =20 =0C LDAP Replication Architecture Model October = 2003 =20 =20 The architecture and the protocols are intended to support=20 heterogeneous directory networks consisting of LDAP server instances=20 based on different vendor implementations.=20 =20 A range of deployment scenarios is supported, including multi-master=20 and single-master topologies. Replication networks may include=20 transitive and redundant relationships between LDAP servers.=20 =20 The controlling framework used to define the relationships, types,=20 and state of replicas of the directory content is defined. In this=20 way the directory content can itself be used to monitor and control=20 the replication network. The directory schema is extended to define=20 object classes, auxiliary classes, and attributes that describe=20 areas of the namespace which are replicated, LDAP servers which hold=20 replicas of various types for the various partitions (_Replication=20 Contexts_) of the namespace, LDAP Access Points (network addresses)=20 where such LDAP servers may be contacted, which namespace replicas=20 are held on given LDAP servers, and the progress of replication=20 operations. Among other things, this knowledge of where directory=20 content is located could serve as the basis for dynamic generation=20 of LDAP referrals.=20 =20 An update transfer protocol, which actually brings a replica up to=20 date with respect to changes in directory content at another=20 replica, is defined using LDAPv3 protocol extensions. The=20 representation of directory content and changes will be defined by=20 the LDAP Replication Update Transfer Protocol sub-team. Incremental=20 and full update transfer mechanisms are described. Replication=20 protocols are required to include initial population, change=20 updates, and removal of directory content.=20 =20 Security information, including access control policy will be=20 treated as directory content by the replication protocols. =20 Confidentiality and integrity of replication information is required=20 to be provided by lower-level transport/session protocols such as=20 IPSEC and/or TLS.=20 =20 3.2 Document Objectives=20 The objectives of this document are:=20 =20 a) To present the architecture and theory of operation for LDUP so=20 that it provides a consistent basis for all detailed design=20 documents associated with this LDAP replication service. The=20 Information Model, Update Transfer Protocol, and Update Resolution=20 Procedure documents are among the targeted LDUP design documents.=20 b) To provide an architectural solution for each clause of the=20 requirements document [LDUP Requirements].=20 c) To collect and summarize LDAP Data Model and Operational Behavior=20 constraints defined for LDAP in RFC 2251 [See Appendix A], that are=20 to be preserved in LDAP replication.=20 =20 =0C LDAP Replication Architecture Model October 2003 =20 d) Where possible, to derive and present appropriate information=20 from other ongoing IETF work (to the extent necessary to further=20 define LDUP). The purpose such an exercise would be to avoid tying=20 the LDUP working group to the schedule of any other working group.=20 =20 e) Present some useful concepts and their utility that are supported=20 in existing commercial directory products. Even if these concepts=20 were not adopted by subsequent LDUP protocol standards, it would=20 still be useful to relate the LDUP design choices and alternatives.=20 =20 In addition to the above objectives document has to address, it=20 should do so without infringing upon known registered intellectual=20 property rights.=20 =20 =20 3.3 Document Non-Objectives=20 =20 This document does not address the following issues, as they are=20 considered beyond the scope of the Working Group.=20 A) How LDAP becomes a distributed directory. There are many issues=20 beyond replication that should be considered. Such as, support for=20 external references, algorithms for computing referrals from the=20 distributed directory knowledge, etc.=20 =20 B) Specifying management protocols to create Replication Contexts or=20 new Replicas. LDAP may be sufficient for this. The document=20 describes how new Replication Contexts and Replicas are represented,=20 in the directory, as entries, attributes, and attribute values.=20 =20 C) How transactions will be replicated. However, the architecture=20 should not knowingly prevent or impede them, given the Working=20 Group's incomplete understanding of the issues at this time.=20 =20 D) The problems of replication between implementations without a=20 common schema representation, and hence require information mapping=20 to achieve synchronization between them.=20 =20 3.4 Existing Implementations=20 =20 In order to define a standard replication scheme that may be readily=20 implemented we must consider the architectures of current LDAP=20 server implementations. Existing systems currently support=20 proprietary replication schemes based on one of two general=20 approaches: log-based or state-based. The approach chosen in=20 subsequent LDUP protocol design is neither stipulated nor assumed in=20 this architecture draft, although certain sections of this document=20 contain discussions of issues in the above approaches. =20 =20 Implementations based on the original University of Michigan LDAP=20 server code record LDAP operations to a operation log. During a=20 replication session operations are replayed from this log to bring=20 the Consumer replica up to date. Example implementations of this=20 =20 LDAP Replication Architecture Model October 2003 =20 type at this time are the IBM SecureWay, Innosoft, Netscape, Open LDAP = and Oracle directory servers.=20 =20 3.5 Terms and Definitions=20 The definitions from the Replication Requirements document have been=20 copied here and extended.=20 =20 For brevity, an LDAP server implementation is referred to throughout=20 as 'the server'.=20 =20 The LDAP update operations; Add, Delete, Modify, Modify RDN (LDAPv2)=20 and Modify DN (LDAPv3), are collectively referred to as LDAP Update=20 Operations.=20 =20 A Naming Context is a subtree of entries in the Directory=20 Information Tree (DIT). There may be multiple Naming Contexts=20 stored on a single server. Naming Contexts are defined in section 17=20 of [X501].=20 =20 A _Replication Context_ represents a section of DIT defining a unit=20 of administration for replication. A Replication Context is based=20 at an entry identified as its root and includes all its subordinate=20 entries down the tree to its leaves, or until another Replication=20 Context is encountered. A Naming Context held by a server may be=20 made up of one or more non-overlapping Replication Contexts. Non- replicated portions of a Naming Context may not be explicitly=20 identified as a Replication Context.=20 =20 A Replica is a replicated instance of a _Replication Context.=20 =20 A _Replication Context_ is said to be single-mastered if there is=20 only one Replica where it may be updated, and multi-mastered if=20 there is more than one Replica where it may be updated.=20 =20 A Replication Relationship is established between two or more=20 Replicas that are hosted on servers that cooperate to service a=20 common area (the Replication Context) of the DIT. =20 =20 The DIT of servers that host replicas need not be entirely=20 symmetric. The DIT areas of the related Replicas among the servers=20 are expected to be symmetric, but each server could potentially=20 maintain additional DIT areas that are independent.=20 =20 A Replication Agreement is defined between two parties of a=20 Replication Relationship. A Replication Agreement is associated=20 with a set of replicas and defines properties such as the Update=20 Transfer Protocol to be used, and the Replication Schedule of a=20 Replication Session.=20 =20 A Replication Session is an LDAP session between the two servers=20 identified by a replication agreement. Interactions occur between=20 =20 LDAP Replication Architecture Model October 2003 =20 the two servers, resulting in the transfer of updates from the=20 supplier replica to the consumer replica.=20 =20 The Initiator of a Replication Session is the initiating server.=20 =20 A Responder server responds to the replication initiation request=20 from the Initiator server.=20 =20 A Supplier server is the source of the updates to be transferred.=20 =20 A Consumer server is the recipient of the update sequence.=20 =20 The Update Transfer Protocol is the means by which the Replication=20 Session proceeds. It defines the protocol for exchanging updates=20 between the Replication Relationship partners.=20 =20 A Replication Update is an LDAP Extended Operation that contains=20 updates to be applied to the DIT. The Update Transfer Protocol=20 carries a sequence of these messages from the Supplier to the=20 Consumer.=20 =20 The Update Resolution Procedures repair constraint violations that=20 occur when updates to a multi-mastered Replica collide.=20 =20 A Fractional Entry Specification is a list of entry attributes to be=20 included, or a list of attributes to be excluded in a replica. An=20 empty specification implies that all entry attributes are included.=20 =20 A Fractional Entry is an entry that contains only a subset of its=20 original attributes. It results from the replication of changes=20 governed by a Fractional Entry Specification.=20 A Fractional Replica is a replica that holds Fractional Entries of=20 its Replication Context.=20 =20 3.6 Deployment Topologies and Associated Consistency Models=20 =20 This replication architecture supports a loose consistency model=20 between replicas of a naming context. It does not attempt to provide=20 the appearance of a single copy of a replica. The contents of each=20 replica may be different, but over time they will be converging=20 towards the same state. This architecture is not intended to support=20 LDAP Clients that require a tight consistency model, where the state=20 of all replicas is always equivalent. =20 =20 While LDUP architecture does not support tight consistency where all=20 replicas are identical in content all the time, LDAP clients can=20 achieve different levels of consistency by following appropriate=20 configuration and access discipline, depending upon the LDUP=20 replication topology.=20 =20 Three levels of consistency are available to LDAP Clients, which are=20 characterized by their LDAP replication deployment topologies.=20 Single-Server, where there is just the Replication Context and no=20 =20 =0C LDAP Replication Architecture Model October 2003 = replicas. Single-master, where there are replicas, but only one may=20 be updated. And, multi-master, where there is more than one replica=20 to which LDAP update operations may be directed. The consistency=20 properties of each model are rooted in their serialization of read=20 and write operations.=20 =20 1) A single-server deployment of a Replication Context provides=20 tight consistency to LDAP applications. LDAP Clients have no choice=20 but to direct all their operations to a single server, serializing=20 both read and write operations.=20 =20 2) A single-mastered deployment of a Replication Context provides=20 both tight and loose consistency to LDAP applications. LDAP Clients=20 must direct all write operations to the single Master Replica, but=20 may direct their reads to any of the replicas. A client experiences=20 tight consistency by directing all its operations to the single=20 Master Replica, and loose consistency by directing any read=20 operations to any other replica.=20 =20 3) A multi-mastered deployment of a Replication Context can provide=20 only loose consistency to LDAP applications. Across the system=20 writes and reads are not serialized. An LDAP Client could direct=20 their read and write operations to a single Master Replica, but they=20 will not receive tight consistency as interleaved writes could be=20 occurring at another replica.=20 =20 Tight consistency can be achieved in a multi-master deployment for a=20 particular LDAP application if and only if all instances of its=20 client are directed towards the same Master Replica, and the=20 application data is not updated by any other LDAP application.=20 Introducing these constraints to an application ensures that writes=20 are serialized providing tight consistency for the application.=20 =20 Future work could make use of the architecture proposed in this=20 document as a basis for allowing clients to request session=20 guarantees from a server when establishing a connection.=20 =20 3.7 LDAP Constraints=20 =20 The LDAP-v3 Internet RFC [LDAPv3] defines a set of Data Model and=20 Operation Behavior constraints that a compliant LDAP server must=20 enforce. The server must reject an LDAP Update Operation if its=20 application to the target entry would violate any one of these LDAP=20 Constraints. [Appendix A contains the original text clauses from RFC=20 2251, and also a summary.]=20 =20 In the case of a single-server or single-mastered Replication=20 Context all LDAP Constraints are immediately enforced at the single=20 Master Replica. An error result code is returned to an LDAP Client=20 that presents an operation that would violate the constraints.=20 =20 In the case of a multi-mastered Replication Context not all LDAP=20 Constraints can be immediately enforced at the Master Replica to=20 which the LDAP Update Operation is applied. This loosely consistent=20 =20 =0C LDAP Replication Architecture Model October 2003 = =20 replication architecture ensures that at each replica all constraints = are imposed, but as updates are replicated constraint violations arise = that cannot be reported to the appropriate client. Any constraint = violations that occur are repaired by a set of update=20 resolution procedures.=20 =20 Any LDAP client that has been implemented to expect immediate=20 enforcement of all LDAP Constraints may not behave as expected=20 against a multi-mastered Replication Context.=20 =20 4 Replication Environment=20 =20 The replication environment would consist of two or more replicas,=20 each characterized with a "replica type". The following replica=20 types are recognized. =20 =20 Note that LDUP protocol design could choose to not support all the=20 types defined below.=20 =20 4.1 Primary Replica=20 =20 The Primary Replica is a full copy of the Replica, to which all=20 applications that require tight consistency should direct their LDAP=20 Operations. There can be only one Primary Replica within the set of=20 Replicas of a given Replication Context. It is also permissible for=20 none of the Replicas to be designated the Primary. The Primary=20 Replica MUST NOT be a Fractional Replica.=20 =20 Some commercial directory products support the notion of a primary=20 replica. This would mean that one of the replicas can be configured=20 to be the "primary" (at any point in time) and certain attributes=20 could be marked as "critical", meaning that they could only be=20 altered on a primary. This configuration would cause all other=20 replicas to deny alterations to these critical attributes and to direct = such modifications transparently (via referrals) to the designated = primary. To remain simple, LDUP Update Protocol is NOT REQUIRED to support = "Primary Replica". Where necessary, it may be possible for = administrators to implement appropriate access policies and other means = of operation redirection to enforce the "primary replica" conventions.=20 =20 =0C LDAP Replication Architecture Model October 2003 = =20 4.2 Master Replica=20 =20 A Master Replica is a Replica that accepts all the LDAP Update=20 Operations, but is not the Primary Replica. There could be none,=20 one, or many Master Replicas within the set of Replicas of a given=20 Replication Context. A Master Replica MUST NOT be a Fractional=20 Replica for this version of LDUP.=20 =20 4.3 Read-Only Replica=20 =20 A Read-Only Replica will accept only non-modifying LDAP operations=20 against data subject to replication. Modifications to DSA-operation=20 attributes, which are not replicated, may of course still be=20 allowed. All other modification operations shall be referred to a=20 Master Replica. The server referred to may be a Supplier of this=20 Replica. =20 =20 4.4 Fractional Replicas=20 =20 Fractional Replicas must always be Read-Only. All LDAP Update=20 Operations must be referred to a Master Replica in this version of=20 LDUP. The server referred to may be a Supplier of this Fractional=20 Replica.=20 =20 5 Information Model=20 =20 This section describes the schema elements that represent the=20 replication topology and replication run time information. The=20 operational information for replication is administered through=20 these entries. The LDUP Working Group will work towards defining an=20 Internet standard to fully detail all these schema elements.=20 =20 LDAP Replication Architecture Model October 2003 =20 =20 5.1 Sub-Entries=20 =20 Replication management entries are to be stored at the base of the=20 Replication Context. They will be of a `ldapSubentry' objectclass=20 to exclude them from regular searches. Entries with the objectclass=20 ldapSubentry are not returned as the result of a search unless a=20 control is included in the request to make them visible.=20 =20 5.2 Glue Entries=20 =20 A glue entry is an entry that contains knowledge of its name only.=20 No other information is held with it. Such glue entries will be=20 distinguished through a special object class defined for that=20 purpose. Glue entries may be created during a replication session to=20 repair a constraint violation.=20 =20 5.3 Unique Identifiers=20 =20 Distinguished names can change, so are therefore unreliable as=20 identifiers. A Unique Identifier must therefore be assigned to each=20 entry as it is created. This identifier will be stored as an=20 operational attribute of the entry, named `entryUUID'. The entryUUID=20 attribute is single valued. A consistent algorithm for generating=20 such unique identifiers should be defined for use in the LDUP=20 standards documents that detail the LDUP information model and LDUP=20 protocols.=20 =20 5.4 Change Sequence Number=20 =20 Change Sequence Numbers (CSNs) are used to impose a total ordering=20 upon the causal sequence of updates applied to all the replicas of a=20 Replication Context. Every LDAP Update Operation is assigned at=20 least one CSN. A Modify operation MUST be assigned one CSN per=20 modification.=20 =20 5.4.1 CSN Composition=20 =20 A CSN is formed of four components. In order of significance they=20 are; the time, a change count, a Replica Identifier, and a=20 modification number. The CSN is composed thus to ensure the=20 uniqueness of every generated CSN. When CSNs are compared to=20 determine their ordering they are compared component by component:=20 first the time, then the change count, then the replica identifier,=20 and finally the modification number.=20 =20 The time component is a year-2000-safe (year 9999-safe, really)=20 representation of the real world time, with a granularity of one=20 second.=20 =20 Because many LDAP Update Operations, at a single replica, may be=20 applied to the same data in a single second, the change count=20 component of the CSN is provided to further order the changes. Each=20 replica maintains a count of LDAP update operations applied against=20 =20 LDAP Replication Architecture Model October 2003 =20 it. It is reset to zero at the start of each second, and is=20 monotonically increasing within that second, incremented for each=20 and every update operation. Should LDAP Update Operations occur at=20 different replicas, to the same data, within the same single second,=20 and happen to be assigned the same change count number, then the=20 Replica Identifier is used to further order the changes.=20 =20 The Replica Identifier is the value of the RDN attribute on the=20 Replica Subentry that represents the Replica. The Replica Identifier=20 could be assigned programmatically or administratively, in either=20 case short values are advised to minimize resource usage. The=20 IA5CaseIgnoreString syntax is used to compare and order Replica=20 Identifier values.=20 =20 The fourth and final CSN component, the modification number, is used=20 for ordering the modifications within an LDAP Modify operation.=20 =20 5.4.2 CSN Representation=20 =20 The preferred CSN representation is: yyyy mm dd hh:mi:ssz # 0xSSSS #=20 replica id # 0xssss=20 =20 The `z' in the time stipulates that the time is expressed in GMT=20 without any daylight savings time offsets permitted, and the 0xssss=20 represents the hexadecimal representation of an unsigned integer.=20 Implementations must support 16 bit change counts and should support=20 longer ones (32, 64, or 128 bits).=20 =20 An example CSN would be " 1998081018:44:31z#0x000F#1#0x0000 ". The=20 update assigned this CSN would have been applied at time=20 1998081018:44:31z happened to be the 16th operation which was=20 applied in that second, was made against the replica with identifier=20 `1', and was the first modification of the operation that caused the=20 change.=20 =20 5.4.3 CSN Generation=20 =20 Because Change Sequence Numbers are primarily based on timestamps,=20 clock differences between servers can cause unexpected change=20 ordering. The synchronization of server clocks is not required,=20 though it is preferable that clocks are accurate. If timestamps are=20 not accurate, and a server consistently produces timestamps that are=20 significantly older than those of other servers, its updates will=20 not have effect and the real world time ordering of updates will not=20 be maintained.=20 =20 However, an implementation may choose to require clock=20 synchronization. The Network Time Protocol [NTP] [SNTP] offers a=20 protocol means by which heterogeneous server hosts may be time=20 synchronized.=20 =20 The modifications that made up an LDAP Modify operation are=20 presented in a sequence. This must be preserved when the resultant=20 changes of this operation are replicated.=20 =20 LDAP Replication Architecture Model October 2003 =20 =20 5.5 Entries, Semantics and Relationships=20 =20 This section defines the organization of operational data for=20 directory replication in terms of the relative placement of the=20 entries that represent Replication Contexts, its Replicas, and their=20 associated Replication agreements. This section also describes the=20 purpose of these objects and abstractly describes their content.=20 =20 A Replication Context defines an area of DIT with independent=20 replication policies. There are many mechanisms available to=20 identify the set of Replication Contexts in a Directory, including=20 through special auxiliary classes or through operational attributes=20 in root DSE pointing to such entries. The LDUP information model=20 standards will detail an appropriate mechanism.=20 =20 Entries representing the set of Replicas associated with a=20 Replication Context are created immediately below (children) the=20 Replication Context entries. Replica entries are defined as=20 subentries and are intended to hold attributes that identify the=20 Replica's LDAP Access Point, its Replica Type, and if it is a=20 Fractional Replica, the attributes it does or does not hold. The=20 attribute value of the entry's Relative Distinguished Name (RDN) is=20 termed the Replica Identifier and is used as a component of each CSN=20 associated with the replica.=20 =20 Immediately subordinate to each Replica Subentry are the entries=20 representing the Replication Agreements between this replica and=20 another replica on some other server in the network. A Replication=20 Agreement entry is associated with exactly one remote replica. These=20 entries are defined to hold attributes identifying the remote=20 Replica associated with this agreement, the scheduling policy for=20 replication operations, including times when replication is to be=20 performed, when it is not to be performed, or the policies governing=20 event-driven replication initiation another Replica, the scheduling=20 policy for replication operations, including times when replication=20 is to be performed, when it is not to be performed, or the policies=20 governing event-driven replication initiation.=20 =20 5.6 Root DSE Attributes=20 =20 =20 The Root DSE attributes carry information that is essential to the=20 operation of the local DSA itself. Each node has its own=20 independent copy of such attributes and hence these are not to be=20 replicated to other nodes. In general this is true for all=20 operational attributes of type "DsaOperation".=20 =20 LDUP information model itself will define Root DSE attributes to=20 identify the set of Replication Contexts and replicas present in an=20 LDAP server.=20 =20 =20 =20 =0C LDAP Replication Architecture Model October 2003 =20 5.7 Replication Context Auxiliary Object Class and Entries=20 =20 Each Replication Context contains attributes that hold common=20 configuration and policy information for all replicas of the=20 Replication Context.=20 =20 A Replication Context Creation attribute records when and where the=20 Replication Context was created.=20 =20 The Replication Context is based at the entry given the auxiliary=20 class, and continues down the tree until leaf entries or another=20 Replication Context is encountered.=20 =20 5.8 Replica Object Class and Entries=20 =20 A replica type characterizes each Replica. This may be Primary,=20 Updateable, or Read-Only. The Replica entry will also include a=20 Fractional Entry Specification for a Fractional Replica.=20 There is a need to represent network addresses of servers holding=20 replicas involved in Replication Agreements. For this, the LDUP=20 information model will define an attribute with an appropriate=20 syntax to represent an LDAP server addresses with which to contact=20 replicas.=20 =20 An Update Vector describes the point to which the Replica has been=20 updated, in respect to all the other Replicas of the Replication=20 Context. The vector is used at the initiation of a replication=20 session to determine the sequence of updates that should be=20 transferred.=20 =20 Enabling LDAP to be a fully distributed service is not an objective=20 for the design of LDUP information model, though the information=20 stored in replica entries could facilitate certain distributed=20 operations.=20 =20 5.9 Lost and Found Entry=20 =20 When replicating operations between servers, conflicts may arise=20 that cause a parent entry to be removed causing its child entries to=20 become orphaned. In this case the Update Resolution Procedures will=20 make the Lost and Found Entry the child's new superior.=20 =20 Each Replica Entry names its Lost and Found Entry, which would=20 usually be an entry below the Replica Entry itself. This well-known=20 place allows administrators, and their tools, to find and repair=20 abandoned entries.=20 =20 5.10 Replication Agreement Object Class and Entries=20 =20 The Replication Agreement defines:=20 =20 1. The schedule for Replication Sessions initiation.=20 =20 LDAP Replication Architecture Model October 2003 =20 2. The server that initiates the Replication Session, either the=20 Consumer or the Supplier.=20 =20 3. The authentication credentials that will be presented between=20 servers.=20 =20 4. The network/transport security scheme that will be employed in=20 order to ensure data confidentiality and integrity.=20 =20 5. The replication protocols and relevant protocol parameters to be=20 used for Full and Incremental updates. An OID is used to identify=20 the update transfer protocol, thus allowing for future extensions or=20 bilaterally agreed upon alternatives.=20 =20 6. If the Replica is Fractional, the Fractional Entry Specification,=20 for the attributes to be included or excluded=20 =20 Permission to participate in replication sessions will be=20 controlled, at least in part, by the presence and content of replica=20 agreements.=20 =20 The Supplier must be subject to the access control policy enforced=20 by the Consumer. Since the access control policy information is=20 stored and replicated as directory content, the access control=20 imposed on the Supplier by the Consumer must be stored in the=20 Consumer's Replication Agreement.=20 =20 5.10.1 Replication Schedule=20 =20 There are two broad mechanisms for initiating replication sessions: =20 (1) scheduled event driven and (2) change event driven. The=20 mechanism used to schedule replication operations between two=20 servers is determined by the Schedule information that is part of=20 the Replication Agreement governing the Replicas on those two=20 servers. Because each Replication Agreement describes the policy=20 for one direction of the relationship, it is possible that events=20 propagate via scheduled events in one direction, and by change=20 events in the other.=20 =20 Change event driven replication sessions are, by their nature,=20 initiated by suppliers of change information. The server that the=20 change is made against schedules a replication session in response=20 to the change itself, so that notification of the change is passed=20 on to other Replicas.=20 =20 Either consumers or suppliers of change information can initiate=20 scheduled event driven replication sessions. The schedule defines a=20 calendar of time periods during which Replication Sessions should be=20 initiated.=20 =20 Schedule information may include both scheduled and change event=20 driven mechanisms. For instance, one such policy may be to begin=20 replication within 15 seconds of any change event, or every 30=20 minutes if no change events are received.=20 =20 LDAP Replication Architecture Model October 2003 =20 =20 6 Replication of Directory Administrative Policy Information=20 Administrative policy information governs the behavior of the=20 directory server. Schema, access control, and replication, all=20 involve administrative policy information. This policy information=20 (irrespective of how it is represented in the directory- as sub- entries, attributes, or attribute values) should be consistently=20 known and enforced by servers managing any replica. Normally,=20 policy information present within a Replication Context is=20 replicated in the same manner as any other directory information. =20 But applicable policy information could reside outside a Replication=20 Context.=20 =20 Administrative policy information associated with directory=20 replication lies within the replication context to which it applies.=20 Hence, fortunately, any replica will also contain (include) all of=20 its applicable replication policy data. On the other hand, some=20 administrative boundaries (administrative areas) for other services=20 might extend to subordinate Replication Contexts. For instance, some=20 prescriptive access control policy applicable to entries in a=20 Replication Context could be represented by an entry that is an=20 ancestor of the root of the Replication Context. For access control=20 policies to be faithfully enforced by a server hosting a replica of=20 such a Replication Context, all applicable prescriptive policy=20 information must also be available within that server.=20 =20 But policy propagation is not an issue for replicated directories=20 only. These same issues are also relevant to distributed=20 directories. Many possible protocols could be conceived to ensure=20 that anywhere in the directory network, all applicable policies are=20 available so that these are enforced appropriately. To support=20 flexible and dependable deployments, DSAs supporting LDUP should=20 also implement IETF standard protocols for policy propagation. It=20 is expected that such an IETF standard protocol will be defined in a=20 way relevant for any LDAP directory deployment, be it distributed,=20 replicated or a combination of both. But defining such a protocol=20 is outside the scope of LDUP architecture.=20 =20 6.1 Schema Replication=20 =20 Given the strict ordering of replication events, schema=20 modifications will normally be replicated prior to entry operations=20 that use them, and subsequent to data deletions that eliminate=20 references to schema elements to be deleted. In a multi-master=20 environment with multiple suppliers, the order of arrival at a=20 consumer node of such changes cannot be guaranteed. The LDUP=20 standards for reconciliation should define procedures for handling=20 such scenarios.=20 =20 7 Change Representation and Update Resolution=20 =20 The state changes in a replica can be introduced via either LDAP=20 Update Operations or via Replication Updates. A CSN is included with=20 LDAP Replication Architecture Model October 2003 =20 all changes made to an entry, its attributes, and attribute values.=20 This state information must be recorded for the entry to enable a=20 total ordering of updates. =20 =20 When an update is performed, the CSN recorded is the CSN assigned at=20 the server where the change was first made. In other words, CSNs are=20 only assigned to changes performed by LDAP client updates and are=20 propagated with other change information. When Replication update=20 is performed at the target replica node the CSN associated with the=20 replicated change being processed is recorded.=20 =20 Each of the LDAP Update operations changes their target entry in=20 different ways, and records the CSN of the change differently. The=20 state information for the resultant state changes is recorded at=20 three levels: the entry level, attribute level, and attribute value=20 level.=20 =20 7.1 Entry Creation and Deletion=20 =20 When an entry is created the CSN of the change is added to the entry=20 as an operational attribute.=20 Deleted entries are marked as deleted through some means such as=20 addition of an object class denoting this sate. Deleted entries are=20 not visible to LDAP clients - they may not be read, they don't=20 appear in lists or search results, and they may not be changed once=20 deleted. Names of deleted entries are available for reuse by new=20 entries immediately after the deleted entry is so marked. It may be=20 desirable to allow deleted entries to be accessed and manipulated by=20 management and data recovery applications, but that is outside the=20 scope of this document.=20 =20 A CSN is recorded for both the RDN, and the Superior DN of the=20 entry.=20 =20 7.2 Attribute Creation and Deletion=20 =20 When all values of an attribute have been deleted, the attribute is=20 marked as deleted and the CSN of the deletion is recorded. The=20 deleted state and CSN are represented and stored by the server in an=20 implementation dependent way and hence may not be accessible by=20 search operations. This state information must be stored to enable=20 the Update Resolution Procedures to be performed. It may be=20 desirable to allow the deleted state and CSN information to be=20 accessed and manipulated by management and data recovery=20 applications, but that is outside the scope of this document.=20 =20 7.3 Attribute Value Changes=20 =20 The Modification CSN for each value is to be set by the server when=20 it accepts a modification request to the value, or when a new value=20 with a later Modification CSN is received via Replication. The=20 modified value and the Modification CSN changes are required to be=20 atomic, so that the value and its Modification CSN cannot be out of=20 LDAP Replication Architecture Model October 2003 =20 synch on a given server. The server stores the state information,=20 but it has no representation on the entry, and may not be the=20 subject of a search operation. It may be desirable to allow the=20 data recovery applications, but that is outside the scope of this=20 document.=20 =20 When the value of an attribute is deleted the state of its deletion=20 must be recorded, with the CSN of the modifying change. It must be=20 stored to enable the Update Resolution Procedures to be performed.=20 =20 7.4 Update Inconsistency=20 The server must reject LDAP client update operations with a CSN that=20 is older than the state information that would be replaced if the=20 operation were performed. This could occur in a replication topology=20 where the difference between the clocks of Master Replicas was too=20 large.=20 =20 8 LDUP Update Transfer Protocol Framework=20 =20 A Replication Session occurs between a Supplier server and Consumer=20 server over an LDAP connection. This section describes the process=20 by which a Replication Session is initiated, started and stopped.=20 =20 The session initiator, termed the Initiator, could be either the=20 Supplier or Consumer. The Initiator sends an LDAP extended operation=20 to the Responder identifying the replication agreement being acted=20 on. The Supplier then sends a sequence of updates to the Consumer.=20 =20 All transfers are in one direction only. A two-way exchange=20 requires two replication sessions - one session in each direction.=20 =20 8.1 Replication Session Initiation=20 =20 The Initiator starts the Replication Session by opening an LDAP=20 connection to its Responder. The Initiator binds using the=20 authentication credentials provided in the Replication Agreement. =20 The LDUP Update Transfer Protocol will define the LDAP extended=20 operation the Initiator should perform to initialize an LDUP=20 session. For the sake of convenience, this extended LDAP operation=20 for initializing a replication session is referred to as the _Start=20 Replication_ operation. Among other things, this operation will=20 identify the role each server will perform, and what type of=20 replication is to be performed. One server is to be the Consumer,=20 the other the Supplier, and the replication may be either Full or=20 Incremental. LDUP Update Transfer protocol could define additional=20 protocol primitives that allow the replicating nodes to reverse=20 their "supplier/consumer" role without having to reinitiate a new=20 replication cycle.=20 =20 8.1.1 Authentication=20 =20 LDAP Replication Architecture Model October 2003 =20 The initiation of a Replication Session is to be restricted to=20 privileged clients. The identity and the credentials for the client=20 eligible for initiating a replication session will be specified as=20 attributes within Replication Agreements.=20 =20 8.1.2 Consumer Initiated=20 =20 The Consumer binds to the Supplier using the authentication=20 credentials specified in the Replication Agreement. The Consumer=20 sends the Start Replication extended request to begin the=20 Replication Session. The Supplier returns a Start Replication=20 extended response containing a response code. The Consumer then=20 disconnects from the Supplier. If the Supplier has agreed to the=20 replication session initiation, it binds to the Consumer and behaves=20 just as if the Supplier initiated the replication.=20 =20 8.1.3 Supplier Initiated=20 =20 The Supplier binds to the Consumer using the authentication=20 credentials provided in the Replication Agreement. The Supplier=20 sends the _Start Replication_ extended request to begin the=20 Replication Session. The Consumer returns a _Start Replication_=20 extended response containing a response code, and possibly its=20 Update Vector. If the Consumer has agreed to the Replication Session=20 initiation, then the transfer protocol begins.=20 =20 8.2 Start Replication Session=20 =20 8.2.1 Start Replication Request=20 =20 The LDUP Update Transfer Protocol will define an LDAP Extended=20 Request, referred to in this document as _Start Replication Request,=20 which is sent from the Initiator to Responder. The parameters of the=20 _Start Replication Request_ would identify the Replication Agreement=20 associated with the session, the Update Transfer Protocol associated =20 with the replication session, and other state information necessary=20 to initiate a replication session between the two servers.=20 =20 8.2.2 Start Replication Response=20 =20 The LDUP Update Transfer Protocol will define an LDAP Extended=20 Response, _Start Replication Response_, sent in reply to a Start=20 Replication Request, from the Responder to the Initiator. The=20 parameters of the Start Replication Response include a response=20 code, and an optional Update Vector.=20 =20 8.3 Update Transfer=20 =20 Each Update Transfer Protocol is identified by an OID. An LDUP=20 conformant server implementation must support those update protocols=20 that are defined as mandatory in the Update Transfer Protocol=20 standard, and may support many others. A server will advertise its=20 protocols in the Root DSE multi- valued attribute=20 'supportedReplicationProtocols'.=20 LDAP Replication Architecture Model October 2003 =20 The Update Transfer Protocol would define the mechanisms for a=20 Consumer to receive a complete (full) update or incremental update=20 based on the current state of replication represented in the Update=20 Vector. A full update is necessary for initializing a consumer=20 replica upon establishment of replication agreements.=20 =20 8.4 End Replication Session=20 =20 The _End Replication Request_ initiated by the supplier terminates a=20 Replication Session. The purpose of this request and response is to=20 secure the state of the Update Vector associated with the two=20 replicas that participated in replication. This is necessary for=20 proper resumption of replication during subsequent LDUP sessions.=20 8.5 Major States of Replicas=20 The state of a Replica controls the activities of the DSA that holds=20 the replica as well as that of other replicas with which it has a=20 replication agreement. This state represents whether a DSA is=20 available for replication with another DSA or not.=20 The following states of replica are envisioned. =20 =20 1) A particular instance of a directory is NOT PARTICIPATING in=20 replication for a given area of replication and a given second=20 instance. In this state the instance need not record change=20 information for changes made in the context.=20 2) A particular instance of a directory is PARTICIPATING but NOT=20 ONLINE for a given area of replication and second instance. In=20 this case changes are recorded and will be sent when the instance=20 goes ONLINE.=20 3) A particular instance is PARTICIPATING and ONLINE for a given=20 area of replication and second instance. In this case changes are=20 being exchanged (subject to replication schedules, etc.). It is=20 possible for a given server to be ONLINE with some of the other=20 servers in the replica group and NOT ONLINE with others.=20 The fourth case (ONLINE and NOT PARTICIPATING) cannot occur.=20 =20 8.5.1 Replica State Changes=20 =20 Replica state changes are expected to trigger as a result of=20 administrative actions such as creation of a new replica instance,=20 removal of a replica, and creation of a replication-agreement=20 referring to a set of replicas. =20 =20 LDUP information model defines a Replica "subentry". The state of a=20 replica is represented within attributes in this Replica subentry.=20 Some of these attributes are of significance and specific to the=20 local DSA (attributes of type "dsaOperation") and hence are not=20 replicated to any other node. Others, however, may be useful to=20 LDAP Replication Architecture Model October 2003 =20 clients and other DSAs (for instance, whether the replica is=20 "ONLINE", it's update vector, or the result of the last replication=20 session for each replica agreement).=20 Each Replica would contain a Replica subentry, one representing=20 itself and one each for all other replicas (associated with the same=20 Replication Context) in the network. A DSA's actions w.r.t to=20 another replica (based on a binding replication agreement) would=20 depend on the replicas own state, as well as that of the state of=20 the latter. These states can be manually set to maintain control=20 over the DSA behavior. Hence, in addition to automatically=20 triggered state changes, it should be possible to manually set these=20 attributes as well.=20 =20 8.6 Integrity & Confidentiality=20 Data integrity (i.e., protection from unintended changes) and=20 confidentiality (i.e., protection from unintended disclosure to=20 eavesdroppers) SHOULD be provided by appropriate selection of=20 underlying transports, for instance TLS, or IPSEC. Replication MUST=20 be supported across TLS LDAP connections. Servers MAY be configured=20 to refuse replication connections over unprotected TCP connections.=20 =20 9 LDUP Update Protocols=20 =20 This Internet-Draft defines two transfer protocols for the supplier=20 to push changes to the consumer. Other protocols could be defined to=20 transfer changes, including those that pull changes from the=20 supplier to the consumer, but those are left for future work.=20 =20 9.1 Replication Updates and Update Primitives=20 =20 LDUP Update Protocol defines how Replication Updates are transferred=20 from the Supplier to the Consumer. Each Replication Update consists=20 of a set of Update Primitives that describe the state changes that=20 have been made to a single entry. Each Replication Update is=20 associated with a single entry identified by its UUID.=20 =20 The Update Transfer Protocol would define a set of Update Primitives=20 each of which codifies an assertion about the state change of an=20 entry that resulted from a directory update operation. The=20 primitives will include sufficient data to allow recreation of=20 corresponding state changes on the consumer's replica. An assertion- based approach has been chosen in such a way that the Primitives are=20 idempotent, meaning that re-application of a Primitive to an Entry=20 will cause no change to the entry. This is desirable as it provides=20 some resilience against some kinds of system failures.=20 =20 Each Update Primitive contains a CSN that represents an ordering=20 among all such primitives generated anywhere in the network. The=20 consumer uses this ordering information to reconcile among those=20 primitives that lead to consistency violation.=20 =20 LDAP Replication Architecture Model October 2003 =20 9.2 Fractional Updates=20 When fully populating or incrementally bringing up to date a=20 Fractional Replica each of the Replication Updates must only contain=20 updates to the attributes in the Fractional Entry Specification.=20 =20 10 LDUP Full Update Transfer Protocol=20 =20 10.1 Full Update Transfer=20 =20 This Full Update Protocol provides a bulk transfer of the replica=20 contents for the initial population of new replicas, and the=20 refreshing of existing replicas. The LDUP Update Transfer protocol=20 standard will define the ways for this transfer is initiated. The = Consumer must replace its entire replica contents with that sent from = the Supplier. The Consumer MUST NOT service any requests for this Naming = Context whilst the full update is being applied. The Consumer should = return a referral to another replica, possibly the supplier. [REF]=20 =20 10.2 Replication Update Generation=20 =20 The entire state of a Replicated Area can be mapped onto a sequence=20 of Replication Updates, each of which contains a sequence of Update=20 Primitives that describe the entire state of a single entry.=20 The sequence of Replication Updates must be ordered such that no=20 entry is created before its parent.=20 =20 10.3 Replication Update Consumption=20 =20 A Consumer will receive the Replication Updates, extract the=20 sequence of Update Primitives, and must apply them to the DIB in the=20 order provided.=20 =20 10.4 Full Update, End Replication Session=20 =20 A Full Update should also result in the replication of all=20 appropriate LDUP meta-data (which are part of the Replication=20 Context), such as the sub-entry representing the Replica being=20 updated and the Update Vector associated with it. The Supplier could=20 be accepting updates whilst the update is in progress. Once the=20 Full Update has completed, an Incremental Update should be performed=20 to transfer these changes.=20 =20 10.5 Interrupted Transmission=20 =20 If the Replication Session terminates before the End Replication=20 Request is sent, then the Replica could be in an inconsistent state. =20 Until the replica is restored to a consistent state, the consumer=20 MUST NOT permit LDAP Clients to access the incomplete replica. The=20 Consumer could refer the Client to the Supplier Replica, or return=20 an error result code.=20 LDAP Replication Architecture Model October 2003 =20 =20 11 LDUP Incremental Update Transfer Protocol=20 =20 For efficiency, the Incremental Update Protocol transmits only those=20 changes that have been made to the Supplier replica that the=20 Consumer has not already received. In a replication topology with=20 transitive redundant replication agreements, changes may propagate=20 through the replica network via different routes.=20 =20 The Consumer must not support multiple concurrent replication=20 sessions with more than one Supplier for the same Replication=20 Context. A Supplier that attempts to initiate a Replication Session=20 with a Consumer already participating as a Consumer in another=20 Replication Session should receive an appropriate error.=20 =20 11.1 Update Vector=20 =20 The Supplier uses the Consumer's Update Vector to determine the=20 sequence of updates that should be sent to the Consumer.=20 =20 Each Replica entry includes an Update Vector to record the point to=20 which the replica has been updated. The vector is a set of CSN=20 values, one value for each known Master Replica. Each CSN value in=20 the vector corresponds to the most recent change known locally that=20 occurred in the Master Replica that this Update Vector value=20 represents.=20 =20 For example, consider two Master Replicas of a Replication Context,=20 one is assigned replica identifier `1', the other replica identifier=20 `2'. Each is responsible for maintaining its own update vector,=20 which will contain two CSNs, one for each replica. So, if both=20 replicas are identical they will have equivalent update vectors.=20 =20 Both Update Vectors =3D=20 =20 {1998081018:44:31z#0x000F#1#0x0000,=20 1998081018:51:20z#0x0001#2#0x0000}=20 =20 Subsequently, at 7pm, an update is applied to replica `2', so its=20 update vector is updated.=20 =20 Replica `1' Update Vector =3D=20 =20 {1998081018:44:31z#0x000F#1#0x0000,=20 1998081018:51:20z#0x0001#2#0x0000}=20 Replica `2' Update Vector =3D=20 =20 {1998081018:44:31z#0x000F#1#0x0000,=20 1998081019:00:00z#0x0000#2#0x0000}=20 =20 Since the Update Vector records the state to which the replica has=20 been updated, a supplier server, during Replication Session=20 initiation, can determine the sequence of updates that should be=20 LDAP Replication Architecture Model October 2003 =20 sent to the consumer. From the example above no updates need to be=20 sent from replica `1' to replica `2', but there is at least one=20 update pending from replica `2' to replica `1'.=20 Because the Update Vector embodies knowledge of updates made at all=20 known replicas it supports replication topologies that include=20 transitive and redundant connections between replicas. It ensures=20 that changes are not transferred to a consumer multiple times even=20 though redundant replication agreements may exist. It also ensures=20 that updates are passed across the replication network between=20 replicas that are not directly linked to each other.=20 =20 It may be the case that a CSN for a given replica is absent from the=20 update vector, for one of two reasons.=20 =20 1. CSNs for Read-Only replicas might be absent because no changes=20 will have ever been applied to that Replica, so there are no changes=20 to replicate.=20 =20 2. CSNs for newly created replicas may be absent because no changes=20 from that replica have yet been propagated.=20 =20 An Update Vector might also contain a CSN for a replica that no=20 longer exists. The replica may have been temporarily taken out of=20 service, or may have been removed from the replication topology=20 permanently. An implementation may choose to retire a CSN after some=20 configurable time period.=20 =20 11.2 Supplier Initiated, Incremental Update, Start Replication Session=20 =20 The Consumer Responder must return its Update Vector to the Supplier=20 Initiator. The Supplier uses this to determine the sequence of=20 Replication Updates that need to be sent to the Consumer.=20 11.3 Replication Update Generation=20 =20 The Supplier generates a sequence of Replication Updates to be sent=20 to the consumer. To enforce LDAP Constraint LDAP Constraints=20 Clauses.6, that the LDAP Modify must be applied atomically, each=20 Replication Update must contain the entire sequence of Update=20 Primitives for all the LDAP Operations for which the Replication=20 Update contains Update Primitives.=20 =20 Stated less formally, for each primitive the update contains, it=20 must also contain all the other primitives that came from the same=20 operation.=20 =20 A log-based implementation might take the approach of mapping LDAP=20 Operations onto an equivalent sequence of Update Primitives. A=20 systematic procedure for achieving this will be fully described in=20 the standard document defining Update Reconciliation Procedures.=20 The Consumer Update Vector is used to determine the sequence of LDAP=20 Operations in the operation log that the Consumer has not yet seen.=20 =20 LDAP Replication Architecture Model October 2003 =20 =20 11.4 Replication Update Consumption=20 =20 A Consumer will receive Replication Updates, extract the sequence of=20 Update Primitives, and must apply them to the DIB in the order=20 provided. LDAP Constraint LDAP Constraints Clauses.6 states that the=20 modifications within an LDAP Modify operation must be applied in the=20 sequence provided.=20 Those Update Primitives must be reconciled with the current replica=20 contents and any previously received updates. In short, updates are=20 compared to the state information associated with the item being=20 operated on. If the change has a more recent CSN, then it is applied=20 to the directory contents. If the change has an older CSN it is no=20 longer relevant and its change must not be effected.=20 =20 If the consumer acts as a supplier to other replicas then the=20 updates are retained for forwarding.=20 =20 11.5 Update Resolution Procedures=20 =20 The LDAP Update Operations must abide by the constraints imposed by=20 the LDAP Data Model and LDAP Operational Behavior, Appendix A. An=20 operation that would violate at least one of these constraints is=20 rejected with an error result code.=20 =20 The loose consistency model of this replication architecture and its=20 support for multiple Master Replicas of a Replication Context means=20 that LDAP Update Operations could be valid at one replica, but not=20 in another. At the time of acceptance, the accepting replica may not=20 have received other updates that would cause a constraint to be=20 violated, and the operation to be rejected.=20 =20 Replication Updates must never be rejected because of a violation of=20 an LDAP Constraint. If the result of applying the Replication Update=20 causes a constraint violation to occur, then some remedial action=20 must be taken to satisfy the constraint. These Update Resolution=20 Procedures are introduced here, and fully described in These Update=20 Resolution Procedures are introduced here will be fully defined=20 within LDUP Update Resolution Procedures.=20 =20 11.5.1 URP: Distinguished Names=20 =20 LDAP Constraints 20.1.1 and 20.1.10 ensure that each entry in the=20 replicated area has a unique DN. A Replication Update could violate=20 this constraint producing two entries, with different unique=20 identifiers, but with the same DN. The resolution procedure is to=20 rename the both entries so that its RDN includes its own unique=20 identifier. This ensures that the DN of both the entries shall be=20 unique.=20 =20 11.5.2 URP: Orphaned Entries=20 =20 =20 LDAP Replication Architecture Model October 2003 =20 LDAP Constraints 20.1.11 ensures that every entry must have a parent=20 entry. A Replication Update could violate this constraint producing=20 an entry with (as yet) no parent entry. The resolution procedure is=20 to create a Glue Entry to take the place of the absent parent. The=20 Glue Entry's superior will be the Lost and Found Entry. This well- known place allows administrators and their tools (including=20 subsequent Replication Sessions) to find and repair orphaned=20 entries.=20 =20 11.5.3 URP: Schema - Single Valued Attributes=20 =20 LDAP Constraint 20.1.7 enforces the single-valued attribute schema=20 restriction. A Replication Update could violate this constraint=20 creating a multi-value single-valued attribute. The resolution=20 procedure is to replace the earlier value of a single-valued=20 attribute with the newer value. In this way the most recently added=20 value will be retained, and the older one discarded.=20 =20 11.5.4 URP: Schema - Required Attributes=20 =20 LDAP Constraint 20.1.7 enforces the schema objectclass definitions=20 on an entry. A Replication Update could violate this constraint=20 creating an entry that does not have attribute values for required=20 attributes. The resolution procedure is to ignore the schema=20 violation and mark the entry as a glue entry for administrative=20 repair or correction in a subsequent replication session.=20 =20 11.5.5 URP: Schema - Extra Attributes=20 =20 LDAP Constraint 20.1.3 and 20.1.7 enforces the schema objectclass=20 definitions on an entry. A Replication Update could violate this=20 constraint creating an entry that has attribute values not allowed=20 by the objectclass values of the entry. The resolution procedure is=20 to ignore the schema violation and mark the entry as a glue entry=20 for administrative repair or correction in a subsequent replication=20 session.=20 =20 11.5.6 URP: Duplicate Attribute Values=20 =20 LDAP Constraint 20.1.5 ensures that the values of an attribute=20 constitute a set of unique values. A Replication Update could=20 violate this constraint. The resolution procedure is to enforce this=20 constraint, recording the most recently assigned CSN with the value.=20 =20 11.5.7 URP: Ancestry Graph Cycle=20 =20 LDAP Constraint 20.4.2.1 prevents against a cycle in the DIT. A=20 Replication Update could violate this constraint causing an entry to=20 become it's own parent, or for it to appear even higher in it's=20 ancestry graph. The resolution procedure is to break the cycle by=20 =20 =0C LDAP Replication Architecture Model October 2003 = =20 changing the parent of the entry closest to be the lost and found=20 entry.=20 =20 11.6 Incremental Update, End Replication Session=20 =20 If the Supplier sent none of its own updates to the Consumer, then=20 the Supplier's CSN within the Supplier's update vector should be=20 updated with the earliest possible CSN that it could generate, to=20 record the time of the last successful replication session. The=20 Consumer will have received the Supplier's Update Vector in the=20 replica sub- entry it holds for the Supplier replica.=20 =20 The Consumer's resultant Update Vector CSN values will be at least=20 as great as the Supplier's Update Vector.=20 =20 The Supplier may request that the Consumer return its resultant=20 Update Vector so that the Supplier can update its replica sub-entry=20 for the Consumer Replica. The Supplier requests this by setting a=20 flag in the End Replication Request. The default flag value is TRUE=20 meaning the Consumer Update Vector must be returned.=20 =20 11.7 Interrupted Transmission=20 =20 If the Replication Session terminates before the End Replication=20 Request is sent then the Consumer's Update Vector may or may not be=20 updated to reflect the updates received. The Start Replication=20 request includes a Replication Update Ordering flag that states=20 whether the updates were sent in CSN order per replica.=20 =20 Since updates are sent in CSN order per replica then it is possible=20 to update the Consumer Update Vector to reflect that some portion of=20 the updates to have been sent have been received and successfully=20 applied. The next Incremental Replication Session will pick up where=20 the failed session left off.=20 =20 12 Purging State Information=20 =20 The state information stored with each entry need not be stored=20 indefinitely. A server implementation may choose to periodically, or=20 continuously, remove state information that is no longer required.=20 The mechanism is implementation- dependent, but to ensure=20 interoperability between implementations, the state information must=20 not be purged until all known replicas have received and=20 acknowledged the change associated with a CSN. This is determined=20 from the Purge Vector [Purge Vector].=20 =20 All the CSNs stored that are lower than the Purge Vector may be=20 purged, because no changes with older CSNs can be replicated to this=20 replica.=20 =20 12.1 Purge Vector=20 =20 The Purge Vector is an Update Vector constructed from the Update=20 Vectors of all known replicas. Below the root of a Replication=20 =20 LDAP Replication Architecture Model October 2003 =20 Context is one sub-entry for each known replica of that Replication=20 Context. Each of those entries contains the last known update vector=20 for that replica. The lowest CSN for each replica are taken from=20 these update vectors to form the Purge Vector. The Purge Vector is=20 used to determine when state information and updates need no longer=20 be stored.=20 =20 12.2 Purging Deleted Entries, Attributes, and Attribute Values=20 =20 The following conditions must hold before an item can be deleted=20 from the Directory Information Base.=20 =20 1) The LDAP delete operation has been propagated to all replication=20 agreement partners.=20 =20 2) All the CSNs in other replica Update Vectors representing changes=20 to be sent to the server holding the deleted entry have advanced=20 beyond the CSN on the deletion (similarly for deleted attributes and=20 attribute values).=20 =20 3) The CSN generator of the other Replicas must have advanced beyond=20 the deletion CSN of the deleted entry. Otherwise, it is possible for=20 one of those Replicas to generate operations with CSNs earlier than=20 the deleted entry.=20 =20 =20 13 Replication Configuration and Management=20 =20 Replication management entries, such as replica or replication=20 agreement entries can be altered on any Master Replica. These=20 entries are implicitly included in the directory entries governed by=20 any agreement associated with this Replication Context. As a=20 result, all servers with a replica of a Replication Context will=20 have access to information about all other replicas and associated=20 agreements.=20 =20 The deployment and maintenance of a replicated directory network=20 involves the creation and management of all the replicas of a=20 Replication Context and replication agreements among these replicas. =20 This section outlines, through an example, the administrative=20 actions necessary to create a new replica and establish replication=20 agreements. Typically, administrative tools will guide the=20 administrator and facilitate these actions. The objective of this=20 example is to illustrate the architectural relationship among=20 various replication related operational information.=20 =20 A copy of an agreement should exist on both the supplier and=20 consumer side for the replication update transfer protocol to be=20 able to start. For this purpose, the root of the Replication=20 Context, replica objects and the replication agreement objects are=20 created first on one of the servers. A copy of these objects is then=20 manually created on the second server associated with the agreement.=20 =20 =20 LDAP Replication Architecture Model October 2003 =20 The scenario below starts with a server (named DSA1) that holds a=20 Master Replica of a Replication Context, RC1. Procedures to=20 establish a Master Replica of the Replication Context on a second=20 server (DSA2) are outlined.=20 =20 Note that when entries are created on two or more separate servers=20 in the operations described below, they need to be created with the=20 same entry UUIDs so that they don't collide with one another when=20 replication of their information actually occurs. This may be done=20 through some administrative control that allows the entry UUID to be=20 set by the create entry operation.=20 =20 1. On DSA1: Add RC1's context prefix to the value of Root DSE=20 attribute 'replicaRoot'.=20 =20 2. On DSA1: Alter the 'ObjectClass' attribute of the root entry of=20 RC1 to include the "replicationContext" auxiliary class.=20 =20 3. On DSA1: Create a replica object, RC1-R1, (as a child of the root=20 of RC1) to represent the replica on DSA1. The attributes include=20 replica type (updateable, read-only etc.) and DSA1 access point=20 information.=20 =20 4. On DSA2: Add RC1's context prefix to the value of Root DSE=20 attribute 'replicaRoot'.=20 =20 5. On DSA2: Create a copy of the root entry of RC1 as a copy of the=20 one in DSA1 (including the replicationContext auxiliary class)=20 =20 6. On DSA2: Create a copy of the replica object RC1-R1=20 =20 7. On DSA2: Create a second replica object, RC1-R2 (as a sibling of=20 RC1-R1) to represent the replica on DSA2.=20 =20 8. On DSA1: Create a copy of the replica object RC1-R2=20 =20 9. On DSA1: Create a replication agreement object, RC1-R1-R2 to=20 represent update transfer from RC1-R1 to RC1-R2. This object is a=20 child of RC1-R1.=20 =20 10. On DSA2: Create a copy of the replication agreement, RC1- R1-R2.=20 11. On DSA2: Create a replication agreement, RC1-R2-R1, to represent=20 update transfer from RC1-R2 to RC1-R1. This object is a child of=20 RC1-R2.=20 =20 12. ON-DSA1: Create a copy of the replication agreement, RC1- R2-R1.=20 =20 After these actions update transfer to satisfy either of the two=20 agreements can commence.=20 =20 If data already existed in one of the replicas, the update transfer=20 protocol should perform a complete update of the data associated=20 with the agreement before normal replication begins.=20 =20 LDAP Replication Architecture Model October 2003 =20 13. Time=20 =20 The server assigns a CSN for every LDAP update operation it=20 receives. Since the CSN is principally based on time, the CSN is=20 susceptible to the Replica clocks drifting in relation to each other=20 (either forwards or backwards).=20 =20 The server must never assign a CSN older than or equal to the last=20 CSN it assigned.=20 =20 The server must reject update operations, from any source, which=20 would result in setting a CSN on an entry or a value that is earlier=20 than possible. The error code serverClocksOutOfSync (72) should be=20 returned if it is clear that the update is not simply an old one=20 that should be silently ignored. In particular, additions or=20 modifications with CSNs prior to those on the servers Purge Vector=20 should be rejected.=20 =20 14 Availability Considerations=20 =20 LDAP directories hold crucial security information affecting=20 security information, including identities, their credentials and=20 associated authorizations. As a result, availability of directory=20 service is critical for the proper operation of almost all the=20 applications accessible over the network. Replicated directory can=20 be implemented to address the availability needs, by employing=20 explicit client failover mechanisms or implicitly through network=20 load balance devices.=20 =20 Since availability is a major objective of implementing replicated=20 directory service, it is important for LDUP implementations to=20 support various deployment procedures such as adding new nodes,=20 deleting nodes or software upgrade of the replicated network nodes,=20 without any service-wide downtime.=20 =20 15 Security Considerations=20 =20 The preceding architecture discussion covers the server=20 authentication, session confidentiality, and session integrity in=20 sections Authentication and Integrity & Confidentiality.=20 =20 The IETF draft "Authentication Methods" for LDAP, provides a=20 detailed LDAP security discussion. Its introductory passage is=20 paraphrased below. [AUTH]=20 =20 A Replication Session can be protected with the following security=20 mechanisms.=20 =20 1) Authentication by means of the SASL mechanism set, possibly=20 backed by the TLS credentials exchange mechanism,=20 =20 2) Authorization by means of access control based on the Initiators=20 authenticated identity,=20 =20 =20 LDAP Replication Architecture Model October 2003 =20 3) Data integrity protection by means of the TLS protocol or data- integrity SASL mechanisms,=20 4) Protection against snooping by means of the TLS protocol or data- encrypting SASL mechanisms,=20 =20 The configuration entries that represent Replication Agreements may=20 contain authentication information. This information must never be=20 replicated between replicas.=20 =20 Updates to a multi-mastered entry may collide causing the Update=20 Resolution Procedures [Update Resolution Procedures] to reject or=20 reverse one of the changes to the entry. The URP algorithms resolve=20 conflicts by using the total ordering of updates imposed by the=20 assignment of CSNs for every operation. As a consequence updates=20 originating from system administrators have no priority over updates=20 originating from regular system users.=20 =20 15.1 Audit Capabilities=20 =20 LDAP servers should enhance their audit capabilities to support=20 collection and management of audit logs about replication=20 activities. Much of replication management operations is sensitive=20 in nature and hence should be auditable. Also important is the=20 auditability of replication sessions by maintaining history log of=20 replication sessions, capturing the servers a node had engaged in=20 replication with in either direction.=20 =20 16 Acknowledgements=20 =20 This document is a product of the LDUP Working Group of the IETF.=20 The contribution of its members is greatly appreciated. =20 17 References=20 =20 [AUTH] _ M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,=20 "Authentication Methods for LDAP", Internet Draft, draft-ietf- ldapext-authmeth-02.txt, June 1998.=20 [BCP-11] _ R. Hovey, S. Bradner, "The Organizations Involved in the=20 IETF Standards Process", BCP 11, RFC 2028, October 1996.=20 =20 [LDAPv3] _ M. Wahl, S. Kille, T. Howes, "Lightweight Directory=20 Access Protocol (v3)", RFC 2251, December1997.=20 =20 [LDUP Requirements] - R. Weiser, E. Stokes 'LDAP Replication=20 Requirements', Internet Draft, draft-weiser- replica-req-02.txt,=20 October, 1999.=20 =20 [NTP] _ D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305,=20 March, 1992.=20 =20 [RFC2119] _ S. Bradner, "Key words for use in RFCs to Indicate=20 Requirement Levels", RFC 2119.=20 =20 =20 LDAP Replication Architecture Model October 2003 =20 [RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, _Lightweight=20 Directory Access Protocol (v3): Attribute Syntax Definitions_, RFC=20 2252, December 1997.=20 =20 [SNTP] _ D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4=20 for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October=20 1996.=20 =20 [TLS] _ J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight=20 Directory Access Protocol (v3): Extension for Transport Layer=20 Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt,=20 June 1998.=20 =20 [X501] _ ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594- 2:1993, Information Technology _ Open Systems Interconnection _ The=20 Directory: Models=20 =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 =20 [X525] _ ITU-T Recommendation X.525 (1997) | ISO/IEC 9594- 9:1997,=20 Information Technology _ Open Systems Interconnection _ The=20 Directory: Replication=20 =20 =20 LDAP Replication Architecture Model October 2003 =20 Intellectual Property Notice=20 =20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to=20 pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; neither does it represent that it=20 has made any effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track and=20 standards-related documentation can be found in BCP-11. Copies of=20 claims of rights made available for publication and any assurances=20 of licenses to be made available, or the result of an attempt made=20 to obtain a general license or permission for the use of such=20 proprietary rights by implementers or users of this specification=20 can be obtained from the IETF Secretariat.=20 =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 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (1998-2003). All Rights Reserved.=20 =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 implementation 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.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =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=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 =20 LDAP Replication Architecture Model October 2003 =20 18 Authors' Address=20 =20 Uppili Srinivasan Oracle, Inc., Redwood Shores, CA=20 E-mail: Uppili.Srinivasan@oracle.com=20 =20 John Merrells Sleepy Cat Software, Inc., Lincoln, MA=20 E-mail: merrells@sleepycat.com=20 =20 Edwards E. Reed Novell, Inc., Provo, UT=20 E-mail: ereed@novell.com=20 =20 LDUP Working Group Mailing List: ietf-ldup@imc.org=20 =20 19 Appendix A _ LDAP Constraints=20 =20 19.1 LDAP Constraints Clauses=20 =20 This is an enumeration of the Data Model and Operation Behaviour=20 constraint clauses defined in RFC 2251. [LDAPv3]=20 =20 1) Data Model - Entries have names: one or more attribute values=20 from the entry form its relative distinguished name (RDN), which=20 MUST be unique among all its siblings. (p5)=20 =20 2) Data Model - Attributes of Entries - Each entry MUST have an=20 objectClass attribute. (p6)=20 =20 3) Data Model - Attributes of Entries - Servers MUST NOT permit=20 clients to add attributes to an entry unless those attributes are=20 permitted by the object class definitions. (p6)=20 =20 4) Relationship to X.500 - This document defines LDAP in terms of=20 X.500 as an X.500 access mechanism. An LDAP server MUST act in=20 accordance with the X.500 (1993) series of ITU recommendations when=20 providing the service. However, it is not required that an LDAP=20 server make use of any X.500 protocols in providing this service,=20 e.g. LDAP can be mapped onto any other directory system so long as=20 the X.500 data and service model as used in LDAP is not violated in=20 the LDAP interface. (p8)=20 =20 5) Elements of Protocol - Common Elements - Attribute - Each=20 attribute value is distinct in the set (no duplicates). (p14)=20 =20 6) Elements of Protocol - Modify Operation - The entire list of=20 entry modifications MUST be performed in the order they are listed,=20 as a single atomic operation. (p33)=20 =20 7) Elements of Protocol - Modify Operation - While individual=20 modifications may violate the directory schema, the resulting entry=20 after the entire list of modifications is performed MUST conform to=20 the requirements of the directory schema. (p33)=20 =20 =20 LDAP Replication Architecture Model October 2003 =20 8) Elements of Protocol - Modify Operation - The Modify Operation=20 cannot be used to remove from an entry any of its distinguished=20 values, those values which form the entry's relative distinguished=20 name. (p34)=20 =20 9) Elements of Protocol - Add Operation - Clients MUST include=20 distinguished values (those forming the entry's own RDN) in this=20 list, the objectClass attribute, and values of any mandatory=20 attributes of the listed object classes. (p35)=20 10) Elements of Protocol - Add Operation - The entry named in the=20 entry field of the AddRequest MUST NOT exist for the AddRequest to=20 succeed. (p35)=20 =20 11) Elements of Protocol - Add Operation - The parent of the entry=20 to be added MUST exist. (p35)=20 =20 12) Elements of Protocol - Delete Operation - ... only leaf entries=20 (those with no subordinate entries) can be deleted with this=20 operation. (p35)=20 =20 13) Elements of Protocol - Modify DN Operation - If there was=20 already an entry with that name [the new DN], the operation would=20 fail. (p36)=20 =20 14) Elements of Protocol - Modify DN Operation - The server may not=20 perform the operation and return an error code if the setting of the=20 deleteoldrdn parameter would cause a schema inconsistency in the=20 entry. (p36)=20 =20 19.2 LDAP Data Model Constraints=20 =20 The LDAP Data Model Constraint clauses as written in RFC 2251=20 [LDAPv3] may be summarised as follows.=20 =20 a) The parent of an entry must exist. (LDAP Constraint 11 & 12.)=20 =20 b) The RDN of an entry is unique among all its siblings. (LDAP=20 Constraint 1.)=20 =20 c) The components of the RDN must appear as attribute values of =20 the entry. (LDAP Constraint 8 & 9.)=20 =20 d) An entry must have an objectclass attribute. (LDAP Constraint 2 & = =20 9.)=20 =20 e) An entry must conform to the schema constraints. (LDAP=20 Constraint 3 & 7.)=20 =20 f) Duplicate attribute values are not permitted.(LDAP Constraint 5.)=20 =20 =20 =20 =20 LDAP Replication Architecture Model October 2003 =20 19.3 LDAP Operation Behaviour Constraints=20 =20 The LDAP Operation Behaviour Constraint clauses as written in RFC=20 2251 [LDAPv3] may be summarized as follows.=20 =20 A) The Add Operation will fail if an entry with the target DN=20 already exists. (LDAP Constraint 10.)=20 =20 B) The Add Operation will fail if the entry violates data=20 constraints:=20 =20 a - The parent of the entry does not exist. (LDAP Constraint 11.)=20 =20 b - The entry already exists. (LDAP Constraint 10.)=20 =20 c - The entry RDN components do not appear as attribute values on=20 the entry. (LDAP Constraint 9.)=20 =20 d - The entry does not have an objectclass attribute. (LDAP=20 Constraint 9.)=20 =20 e - The entry does not conform to the schema constraints. (LDAP Constraint 9.)=20 =20 f - The entry has no duplicated attribute values. (LDAP=20 Constraint 5.)=20 =20 C) The modifications of a Modify Operation are applied in the order=20 presented. (LDAP Constraint 6.)=20 =20 D) The full set of modifications of a Modify Operation are applied=20 as one atomic unit. (LDAP Constraint 6.)=20 =20 E) A Modify Operation will fail if it results in an entry that=20 violates data constraints:=20 =20 a - If it attempts to remove distinguished attribute values.=20 (LDAP Constraint 8.)=20 =20 b - If it removes the objectclass attribute. (LDAP Constraint=20 2.)=20 =20 c - If it violates the schema constraints. (LDAP Constraint 7.)=20 =20 d - If it creates duplicate attribute values. (LDAP Constraint 5.)=20 =20 F) The Delete Operation will fail if it would result in a DIT that=20 violates data constraints:=20 =20 a - The deleted entry must not have any children.=20 (LDAP Constraint 12.)=20 =20 =20 LDAP Replication Architecture Model October 2003 =20 G) The ModDN Operation will fail if it would result in a DIT or=20 entry that violates data constraints:=20 =20 a - The new Superior entry must exist. (Derived LDAP Data Model=20 Constraint A)=20 =20 b - An entry with the new DN must not already exist. (LDAP=20 Constraint 13.)=20 =20 c - The new RDN components do not appear as attribute values on=20 the entry. (LDAP Constraint 1.)=20 =20 d - If it removes the objectclass attribute. (LDAP Constraint=20 2.)=20 =20 e - It is permitted for the operation to result in an entry that=20 violates the schema constraints. (LDAP Constraint 14.)=20 =20 19.4 New LDAP Constraints=20 =20 The introduction of support for multi-mastered entries, by the=20 replication scheme presented in this document, necessitates the=20 imposition of new constraints upon the Data Model and LDAP Operation=20 Behaviour.=20 =20 19.4.1 New LDAP Data Model Constraints=20 =20 1) Each entry shall have a unique identifier generated by the UUID=20 algorithm available through the `entryUUID' operational attribute.=20 The entryUUID attribute is single valued.=20 =20 19.4.2 New LDAP Operation Behaviour Constraints=20 1) The LDAP Data Model Constraints do not prevent cycles in the ancestry = graph. Existing constraints Data Model Constraint _ New LDAP Data Model = Constraints _ (a) and Operation Constraint _ New LDAP Operation = Behaviour Constraints _ (B) would prevent this in the single master = case, but not in the presence of multiple masters.=20 2) The LDAP Data Model Constraints state that only the LDAP Modify = Operation is atomic. All other LDAP operations, namely, ADD, DELETE and = MODDN are also considered to be atomically applied to the DIB.=20 =20 =0C ------=_NextPart_000_002E_01C39670.A6BE51A0-- From owner-ietf-ldup@mail.imc.org Mon Oct 20 23:51:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21077 for ; Mon, 20 Oct 2003 23:51:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L2gBI7020769 for ; Mon, 20 Oct 2003 19:42:11 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9L2gBqk020768 for ietf-ldup-bks; Mon, 20 Oct 2003 19:42:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [216.98.200.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9L2g9I7020762 for ; Mon, 20 Oct 2003 19:42:09 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (p209.n-dcpop06.stsn.com [63.240.221.209]) by echt.caledonia.net; Mon, 20 Oct 2003 20:41:35 -0600 Reply-To: From: "Chris Apple" To: "'Uppili.Srinivasan'" Cc: , , , Subject: RE: Date: Mon, 20 Oct 2003 22:40:54 -0400 Organization: DSI-Consulting, Inc. Message-ID: <011901c3977c$c6a92aa0$2213190a@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011A_01C3975B.3F978AA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <003201c396ab$5b4c31c0$93c81990@acer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_011A_01C3975B.3F978AA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message received. John and I will review the document and get things = moving along. =20 Chris. -----Original Message----- From: Uppili.Srinivasan [mailto:Uppili.srinivasan@oracle.com]=20 Sent: Sunday, October 19, 2003 9:42 PM To: internet-drafts@ietf.org Cc: merrells@sleepycat.com; ietf-ldup@imc.org; ereed@novell.com; capple@dsi-consulting.net; john.strassner@intelliden.com Subject:=20 Drafts Editor - Please publish the attached as draft-ietf-ldup-model-09.txt. LDUPers - Attached is the latest version of the LDUP Profiles draft. I have made = the changes that have been suggested by various reviewers. Most notably, = thanks to Jerry Maziarsky for a detailed review and comments to address areas ambiguity. =20 Per the plan stated in Vienna, I would like to submit this for WG last = call. The following edits have been made in this version of the draft: (1) The relationships between different deployment configurations = (single vs multi-master) and consistency models (synchronous vs asynchronous) are clarified.=20 (2) The architecture spells out that the DITs of replicating directories need not be symmetric. Only the areas under replication need be. =20 (3) A section is added to highlight availability considerations when = nodes are added, deleted or upgraded without adversely affecting total system up-time, since one of the objectives of replication is high = availability.=20 (4) The scope of LDUP is clarified as not for only among homogenous = DSAs (same vendor) but also for heterogeneous DSAs (multi-vendor). Thanks, Uppili Srinivasan=20 ------=_NextPart_000_011A_01C3975B.3F978AA0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Message received. John and I will review the = document and=20 get things moving along.
 
Chris.
-----Original Message-----
From:=20 Uppili.Srinivasan [mailto:Uppili.srinivasan@oracle.com] =
Sent:=20 Sunday, October 19, 2003 9:42 PM
To:=20 internet-drafts@ietf.org
Cc: merrells@sleepycat.com;=20 ietf-ldup@imc.org; ereed@novell.com; capple@dsi-consulting.net;=20 john.strassner@intelliden.com
Subject: =

Drafts Editor -

Please publish the attached as=20 draft-ietf-ldup-model-09.txt.

LDUPers -

Attached is the = latest=20 version of the LDUP Profiles draft.  I have made the changes that = have=20 been suggested by various reviewers. Most notably, thanks to Jerry = Maziarsky=20 for a detailed review and comments to address areas = ambiguity.  =20

Per the plan stated in Vienna, I would like to submit this for = WG last=20 call.

The following edits have been made in this version of the = draft:

(1) The relationships between different deployment=20 configurations (single vs multi-master) and consistency models = (synchronous vs=20 asynchronous) are clarified.

(2) The architecture spells out = that the=20 DITs of replicating directories need not be symmetric.  Only the = areas=20 under replication need be. 

(3) A section is added to = highlight=20 availability considerations when nodes are added, deleted or upgraded = without=20 adversely affecting total system up-time, since one of the objectives = of=20 replication is high availability.

(4) The scope of LDUP is = clarified=20 as not for only among homogenous  DSAs (same vendor) but also for = heterogeneous DSAs (multi-vendor).

Thanks,
Uppili = Srinivasan=20
------=_NextPart_000_011A_01C3975B.3F978AA0-- From owner-ietf-ldup@mail.imc.org Tue Oct 21 16:17:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05654 for ; Tue, 21 Oct 2003 16:17:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LK1ZI7038246 for ; Tue, 21 Oct 2003 13:01:35 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LK1Zww038245 for ietf-ldup-bks; Tue, 21 Oct 2003 13:01:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LK1UI7038240 for ; Tue, 21 Oct 2003 13:01:32 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941; Tue, 21 Oct 2003 16:01:20 -0400 (EDT) Message-Id: <200310212001.QAA04941@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-09.txt Date: Tue, 21 Oct 2003 16:01:20 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Replication Architecture Author(s) : J. Merrells, E. Reed, U. SRINIVASAN Filename : draft-ietf-ldup-model-09.txt Pages : 35 Date : 2003-10-21 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-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-model-09.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-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21154200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-model-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-model-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21154200.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Oct 22 09:37:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08321 for ; Wed, 22 Oct 2003 09:37:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDLmI7039992 for ; Wed, 22 Oct 2003 06:21:48 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MDLm2p039991 for ietf-ldup-bks; Wed, 22 Oct 2003 06:21:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from localhost.localdomain (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MDLjI7039985 for ; Wed, 22 Oct 2003 06:21:46 -0700 (PDT) (envelope-from rmoats@lemurnetworks.net) Received: from lemurnetworks.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9MDL195003485; Wed, 22 Oct 2003 08:21:02 -0500 Message-ID: <3F96843C.8000404@lemurnetworks.net> Date: Wed, 22 Oct 2003 08:21:00 -0500 From: Ryan Moats User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org, ietf-ldup@imc.org Subject: submission: draft-ietf-ldup-infomod-08.txt Content-Type: multipart/mixed; boundary="------------050608070409010502060409" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------050608070409010502060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To the I-D editor: Attached is draft-ietf-ldup-infomod-08.txt for the repository. To LDUP: Attached is draft-ietf-ldup-infomod-08.txt, ready for last call. As such, we've extracted the document changes section and place it here for reference. John and Chris, please schedule a last call when you can. Ryan Moats (for the authors) ===================Recent document changes Changes in this version (-08) - Explicitly change replicaAgreement to not be a subentry. - Explicitly allow multiple replicaSubentries per replicaContext - Added replicaDN to examples. - Remove discussion of "Primary" replica. - Clarify information that must be present in all replicas (replicaSubentries) and what replicaAgreements and associated information must be present in a replica. Changes made to previous versions - Fixed OID values to have correct prefix: 2.16.840.1.113719.1.142 - Fixed formatting to avoid strange single quote characters in text formatted file - Changed name of attrs1 and attrs2 to attrReplicationGroup1 and attrReplicationGroup2 - Made obsolete timeScheduledSubentry and eventScheduledSubentry - Re-based replicaSubEntry and other object classes on subentry schema from draft-zeilenga-ldap-subentry-00.txt - Clarified that root DSE attribute replicaSubentries should be automatically updated on both add and delete of these entries - Made obsolete replicaSubEntry and replicaAgreementSubentry object classes - Defined replacement object classes replicaSubEntry2 and replicaAgreementSubentry2 - Defined replicaEventSchedule and replicaTimeSchedule object classes and associated attributes - Defined attributes that must appear in the server's root DSE entry as part of the LDUP information model - Many editorial fixes - Clarified the notion that the updateVector is a replicated attribute and thus, itself, has CSN information for its attribute values - Introduced the notion that replicaAgreementSubentry entries represent constraints to what is, by default, "immediate" replication session initiation - LDAP Schedule Subentry definition is defined. - LDAP Access Point removed in favor of just using the DN of the server holding the replica (so a new syntax isn't required). - LDAP Change Sequence Number syntax eliminated in favor of just calling it a CaseIgnoreString, so new comparison rules aren't required. - Deleted ldapSearchFilter definition from here. Sparse replicas is deferred. Might sparse be supported for single-master configurations (read-only, of course). - Fractional are okay in multi-master configurations, but again, only on read-only replicas. - Changed the naming convention upper-lower case usage to look less weird.- Consistency discussion - Schema document must clearly indicate that clients can and should inspect the replica subentries to understand the single-master/multi-master nature of the naming context to which they're talking. - The paradigm change, to distributed data, needs to be exhaustively discussed in the profile documents. How old applications which assume single-master behave or misbehave in a multi-master environment is critical to make clear. Draw examples from SMP pre-emptive programming practices, from DNS vs. host file models, etc. --------------050608070409010502060409 Content-Type: text/plain; name="draft-ietf-ldup-infomod-08.txt" Content-Disposition: inline; filename="draft-ietf-ldup-infomod-08.txt" Content-Transfer-Encoding: 8bit Internet Draft Richard Huber Document: draft-ietf-ldup-infomod-08.txt AT&T Laboratories Expires: April 30 2004 John McMeeking Intended Category: Experimental IBM Ryan Moats Lemur Networks October 2003 LDUP Replication Information Model draft-ietf-ldup-infomod-08.txt 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." 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. This Internet-Draft expires March, 2002. 2. Abstract [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 are extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (i.e., 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 Huber, et al Expires April 2004 [Page 1] LDUP Information Model where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. The controlling framework by which the relationships, types, and health of replicas of the directory content will be defined so that, as much as possible, directory content is itself used to monitor and control the environment. Security information, including access control policy identifiers and information will be treated as directory content by the replication protocols when specified by the LDAPEXT group. Note that [RFC2820] specifies that access control information must be stored as LDAP attributes. Access control information will be replicated properly under any access control scheme that satisfies this requirement. The information model will describe required and optional house- keeping duties for compliant systems to implement, such as garbage collection of deleted objects, reconciliation of moved and renamed objects, update sequencing and transaction bracketing of changes, etc. 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 [RFC2119]. The sections below reiterate these definitions and include some additional ones. Huber, et al Expires April 2004 [Page 2] LDUP Information Model 3. Table of Contents 1. Status of this Memo...........................................1 2. Abstract......................................................1 3. Table of Contents.............................................3 4. Introduction..................................................5 4.1. Scope......................................................5 4.2. Terms and Definitions......................................5 5. Data design...................................................5 6. Directory Knowledge...........................................5 7. Schema........................................................6 7.1. Data Structure Definitions.................................6 7.1.1. LdapChangeSequenceNumber.................................7 7.2. Attribute Definitions......................................8 7.2.1. supportedReplicationProtocols............................8 7.2.2. attributeExclusionFilter.................................8 7.2.3. attributeInclusionFilter.................................9 7.2.4. replicaURI...............................................9 7.2.5. replicationStatus.......................................10 7.2.6. replicaType.............................................10 7.2.7. updateVector............................................11 7.2.8. replicaSecondaryURI.....................................11 7.2.9. lostAndFoundEntryDN.....................................12 7.2.10. replicaOnline...........................................12 7.2.11. replicaDN...............................................12 7.2.12. replicationMechanismOID.................................12 7.2.13. replicationCredentialsDN................................13 7.2.14. replicationScheduleDN...................................13 7.2.15. updateVectorTrigger.....................................13 7.2.16. secondsToWaitDefault....................................14 7.2.17. secondsToWait1..........................................14 7.2.18. attrReplicationGroup1...................................15 7.2.19. secondsToWait2..........................................15 7.2.20. attrReplicationGroup2...................................16 7.2.21. scheduleTimePeriod......................................16 7.2.22. scheduleMonthOfYearMask.................................16 7.2.23. scheduleDayOfMonthMask..................................16 7.2.24. scheduleDayOfWeekMask...................................17 7.2.25. scheduleTimeOfDayMask...................................17 7.2.26. scheduleLocalOrUtcTime..................................17 7.3. Class Definitions.........................................17 7.3.1. ReplicationContext......................................17 7.3.2. replicaSubentry.........................................18 7.3.3. replicaAgreement........................................19 7.3.4. replicaEventSchedule....................................20 7.3.5. replicaTimeSchedule.....................................22 Huber, et al Expires April 2004 [Page 3] LDUP Information Model 8. Semantics of the information model...........................22 9. Object Identifier Assignments................................25 10. Security Considerations....................................27 11. Copyright Notice...........................................28 12. Acknowledgements...........................................29 13. Authors' Addresses.........................................29 Huber, et al Expires April 2004 [Page 4] LDUP Information Model 4. Introduction 4.1. Scope This document describes schema for information used to control replication. Management and status schema elements are defined. Semantic interpretation of schema elements, including any special handling expectations, are provided here. 4.2. Terms and Definitions Definitions are provided in [RFC3384]. 5. Data design As described in [LDUP Model], knowledge of replicated portions of the directory information tree (DIT) is stored in the directory itself. An auxiliary class is defined to designate containers, or nodes, in the DIT which are the root-most, or base, of replication contexts. Directory subentries [LDAP Subentry] are used to hold information about replicas. In defining the replication agreement data model, describing the constraints under which replication between two replicas will occur, this document describes only the least set of information necessary to ensure interoperability between implementations. The current document defines data elements sufficient to describe most common replication needs. The specification of complex replication agreements and constraints is better served by usage of the emerging "policy model" [Policy schema]. 6. Directory Knowledge Information about what replicas exist, what they contain, their types, where they are stored, and how they may be contacted inevitably provides the basis for distributed directory knowledge. As namespaces from stand-alone servers are inter-connected with one another, this replica information can and will be used by name resolution operations to locate servers holding copies of specific objects, and to optimize distributed searches which span multiple Naming Contexts. However, the focus of this document is NOT to fully enable such distributed directory uses. Instead, we are focused on how portions of the namespace (Directory Information Tree - DIT) may be replicated, and how those replicas are configured and related to one another via Replication Agreements. Huber, et al Expires April 2004 [Page 5] LDUP Information Model As such, the following high-level description (from [LDUP Model]) of the information model envisioned is provided as a reference for the reader before presenting the detailed specifications. Generally, the DSE Naming Context attribute of an LDAPv3 server names the Naming Contexts for which there are replicas on that server. The Replication Context Auxiliary Class (replicationContext) is added to container objects which may have separately defined replication policy. Immediately subordinate to a Replication Context object are the Replica Subentry containers which identify where the identified replica resides (i.e., its LDAP Access Point), its type (Updateable, ReadOnly), if it is sparse, the LDAP search filter which defines what object classes it holds, and if it is fractional, the attributes it does or does not hold. Immediately subordinate in the namespace to a Replica Subentry are Replication Agreement leaf entries which each identify another Replica, the scheduling policy for replication operations (including times when replication is to be performed, when it is not to be performed, or the policies governing event-driven replication initiation). These Replication Agreements are used to specify constraints on when the replica will supply what changes to the "pointed to" other replica, as either the replication initiator or responder. Replication Agreements are not defined to cover the following advanced policy characteristics: - when a replica would allow consumers to request a replication session - when a replica would allow suppliers to start a replication session - when a replica would request a replication session from a supplier. These advanced policy specifications imply the specification of complex replication agreements and constraints. This is better served by usage of the emerging "policy model" [Policy schema]. Interoperable policies for replication agreements is left as a follow-on work effort. 7. Schema 7.1. Data Structure Definitions For the purposes of defining the encoding rules for attribute structures, the BNF definitions in section 4.1 of [RFC2252] will be used. They are based on the BNF styles of [RFC822]. Huber, et al Expires April 2004 [Page 6] LDUP Information Model To avoid requiring new syntax support to be added unnecessarily to existing LDAPv3 directory service implementations (and the accompanying matching rules, etc. they would entail), a string encoding is defined for ldapChangeSequenceNumber which can use CaseIgnoreString matching rules for ordering and equality. 7.1.1. LdapChangeSequenceNumber ( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Change Sequence Number' ) Values in this syntax are encoded according to the following BNF. Note there MUST NOT be any white space separators, unless they are in replicaID, which must be encoded according to the instructions below. This encoding is specified so that the CaseIgnoreString equality and ordering rules will work correctly when replicaNumber is used. When replicaID is used, CaseIgnoreString comparison rules will not work unless each replicaID is exactly the same length with no padded white spaces (because CaseIgnoreString suppresses duplicate adjacent white space when it compares two strings). LDAPChangeSequenceNumber = GeneralizedZTime "#" \ S1 "#" replicaID "#" S2 GeneralizedZTime = yyyy | mm | dd | hh | mi | ss | "Z" yyyy = dddd mm = dd dd = dd hh = dd mi = dd ss = dd replicaID = dstring S1, S2 = numericstring The GeneralizedTime is used as described (cf. [X680] section 39.3 case b) without separators or white space, and representing a coordinated universal time (i.e., Greenwich Mean Time, or GMT). All times referenced by this syntax MUST be normalized to GMT - no local times, nor time zone offsets are permitted. To simplify comparisons of two CSNs, the "Z" MUST be the UTF-8 capital-Z character. The ReplicaID represents the specific Replica of this Naming Context where the event associated with this Huber, et al Expires April 2004 [Page 7] LDUP Information Model LDAPChangeSequenceNumber occurred. Note that in actual transfer, the replicaID MAY be represented by a number which is associated with the entryUUID of the replicaSubEntry associated with the replica (see the specification of the replicaIDTable in [LDUP Update Protocol]). When associated with an item of information within a replica, the replicaID should be traceable to the entryUUID of the replicaSubEntry associated with the replica on which the modification was made. This allows for compressed internal storage of change sequence numbers while still ensuring that change sequence numbers will be universally unique regardless of the replication context from which they were first produced. S1 and S2 are sequence numbers which are used to order two events with the same Generalized Time and replicaID. In order to use string matching rules for equality and ordering with values with this encoding, the length of each field must be consistent. Thus, all instances of S1 MUST be represented with the same number of digits, using leading zeros as necessary. The same with S2 and replicaID. 7.2. Attribute Definitions 7.2.1. supportedReplicationProtocols ( 2.16.840.1.113719.1.142.4.x NAME 'supportedReplicationProtocols' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'set of OIDs which represent the (set of) protocols supported by this server' ) This attribute is added to the root DSE entry of servers which support replication as defined by [LDUP Model]. 7.2.2. attributeExclusionFilter ( 2.16.840.1.113719.1.142.4.1 NAME 'attributeExclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE USAGE dSAOperation ) The attributeExclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described in section 4.5.1 Search Request of [RFC2251] with the following interpretation: an empty attributeExclusionFilter means that no attributes are excluded; the special values "*" and "1.1" mean that ALL attributes are excluded. A non-empty attributeExclusionFilter attribute on a replica subentry describes the attributes NOT PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes Huber, et al Expires April 2004 [Page 8] LDUP Information Model they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. A non-empty attributeExclusionFilter attribute on a replication agreement subentry describes which additional attributes are to be excluded from the updates to be sent from the supplier replica to the consumer replica. 7.2.3. attributeInclusionFilter ( 2.16.840.1.113719.1.142.4.2 NAME 'attributeInclusionFilter' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE USAGE dSAOperation ) The attributeInclusionFilter is intended to contain a list of attributes in the form of an AttributeDescriptionList as described in section 4.5.1 Search Request of [RFC2251] with the following interpretation: an empty attributeInclusionFilter means that all attributes are included; the special value "*" means that ALL attributes are included; the special value "1.1" is meaningless and is ignored in this usage. A non-empty attributeInclusionFilter attribute on a replica subentry describes the attributes that may be PRESENT on entries held by that replica. Replicas MUST NOT accept changes for attributes they're not permitted to hold, per the attributeInclusionFilter and attributeExclusionFilter attributes on their replica subentry. It is an error to specify both an attributeExclusionFilter and an attributInclusionFilter in the same replicaSubentry. 7.2.4. replicaURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaURI' DESC 'LDAP URLs which indicate how to connect to this replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) The replicaURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the replica for replication sessions. If all URLs in the replicaURL attribute are not contactable, the replicaSecondaryURL attribute values should be used to establish a replication session with the replica. The replicaURI MUST be an LDAP URL as specified in RFC 2255. The replicaURI SHOULD specify only the host name (or IP address) of the destination replica and possibly a port number. Filters, base DN, and other LDAP URL components MUST be ignored if they are supplied. Huber, et al Expires April 2004 [Page 9] LDUP Information Model 7.2.5. replicationStatus (2.16.840.1.113719.1.142.4.3 NAME 'replicationStatus' DESC 'human readable status of last replication attempt' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) The replicationStatus attribute MAY be used to hold a human readable message describing the most recent replication session attempt for a replication agreement. For example, such a messages might include 1) 9980805162203Z # Success # 2) 19980805162322Z # Failure # Server too busy, try again 3) 19980805170215Z # Failure # Unable to connect to DSA 4) 19980806002301Z # Failure # Authentication failed 5) 19980806003201Z # Failure # lost connection, reset by peer It is suggested, but not required, that the time of a replication attempt (completion, if successful or failure, if not), the result of the attempt, and any additional information about a failure be included in the string message. It is suggested, but not required, that the messages be stored with language tags (English, French, German, Japanese, Chinese, per [RFC2596]) particularly if multiple translations of the error messages are available to the DSA implementers. Sequences of status entries SHOULD be written to log files or other persistent storage, or in multi-valued replication history attributes, but are not specified here. 7.2.6. replicaType (2.16.840.1.113719.1.142.4.4 NAME 'replicaType' DESC 'Enum: 0-reserved, 1-reserved, 2-Updateable, 3-ReadOnly, all others reserved' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE USAGE dSAOperation ) ReplicaType is a simple enumeration, used to identify what kind of replica is being described in a Replica object entry. Huber, et al Expires April 2004 [Page 10] LDUP Information Model A ReadOnly replica only accepts LDAP Search operations (to Read entries, list containers, and search for entries). Because no updates ever originate from ReadOnly replicas, they never have changes to send to another replica. However, a ReadOnly replica may be designated a supplier DSA in a replica agreement, if it is simply passing along information it receives from Updateable replicas about entries and their changes. ReadOnly replicas may be partial replicas. An Updateable replica may accept both LDAP Search operations (to read, list, or search entries), as well as modification operations (to add, modify, or delete entries). The consequences of having partial updateable replicas are not fully understood. LDAP DSAs MAY require updateable replicas to be complete replicas. The way in which replicas change their type, as from ReadOnly to Updateable, is discussed in [LDUP MRM]. Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible combinations of replica types and sparse/fractional replicas. 7.2.7. updateVector ( 2.16.840.1.113719.1.142.4.6 NAME 'updateVector' SYNTAX 1.3.6.1.4.1.1466.115.121.1.TBD EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch NO-USER-MODIFICATION USAGE dSAOperation ) The attribute updateVector is a multi-valued attribute which contains information for a replica describing the latest changes received by the replica from other replicas. There may be only one ldapChangeSequenceNumber entry from each replica in the updateVector. That is to say, there is a unique value constraint on the ReplicaID component of entries in the list. 7.2.8. replicaSecondaryURI ( 2.16.840.1.113719.1.142.4.x NAME 'replicaSecondaryURI' DESC 'LDAP URLs which indicate how to connect to this replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch USAGE dSAOperation ) The replicaSecondaryURI attribute is a multi-valued attribute used to list the set of LDAP URLs that should be used to contact the Huber, et al Expires April 2004 [Page 11] LDUP Information Model replica for replication sessions if all LDAP URLs in the replicaURL attribute are not contactable. 7.2.9. lostAndFoundEntryDN ( 2.16.840.1.113719.1.142.4.x NAME 'lostAndFoundEntryDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the entry under which orphaned entries will be moved during replication update processing by this replica.' ) This attribute indicates the location under which the replica will move orphaned entries that are encountered while performing replication updates. The attribute is single-valued and is specific to each replica. 7.2.10. replicaOnline ( 2.16.840.1.113719.1.142.4.x NAME 'replicaOnline' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE DESC 'indicates whether or not the replica will will initiate and/or respond to replication session start requests.' ) This attribute indicates whether the replica is ready and willing to participate in replication sessions with other replicas that are defined as holding the replication context. 7.2.11. replicaDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicaDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of the consumer replicaSubentry entry that the replicaAgreement links to.' ) This attribute is used to link a replicaAgreement entry (associated with a supplier of replication update information) to the consumer replica that will be contacted by replication sessions constrained by the replicaAgreement. 7.2.12. replicationMechanismOID ( 2.16.840.1.113719.1.142.4.x NAME 'replicationMechanismOID' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch SINGLE-VALUE DESC 'the OID which represents the specific replication protocol used for replication Huber, et al Expires April 2004 [Page 12] LDUP Information Model sessions between the identified supplier and consumer replicas.' ) This attribute identifies the specific replication protocol used for replication sessions between the supplier and consumer replicas associated by the replicaAgreement entry. This attribute must be a value that is within the set of attribute values for the supportedReplicationProtocols attribute in the root DSE entry. 7.2.13. replicationCredentialsDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationCredentialsDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of a separate entry in the directory tree which contains the credentials information used in identifying the supplier replica to the consumer replica when initiating a replication session.' ) This attribute is used to establish a separate entry in the directory tree that will hold the credentials information that is used to establish the supplier's identity at the consumer when starting a replication session. By placing credentials information in a separate entry, "pointed to" with this attribute, credentials information can be placed in a portion of the directory tree that is not replicated across multiple replicas. It can also be “shared” by several replication contexts. 7.2.14. replicationScheduleDN ( 2.16.840.1.113719.1.142.4.x NAME 'replicationScheduleDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE DESC 'name of an entry which contains the specific information used to establish when replication sessions will be initiated by this replica supplier.' ) This attribute is used to "point to" either a replicaEventSchedule or replicaTimeSchedule entry which describes when replication sessions should be initiated by a replica supplier. If not specified, a default schedule is assumed. See the section describing the replicaAgreement for more details. 7.2.15. updateVectorTrigger ( 2.16.840.1.113719.1.142.4.x NAME 'updateVectorTrigger' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE DESC 'indicates whether or not updates made to the replicas updateVector should be treated as Huber, et al Expires April 2004 [Page 13] LDUP Information Model updates that cause the secondsToWaitDefault attribute value to be used in determining when to initiate a replication session.' ) This attribute is used to indicate whether or not changes to the replica's updateVector should be included as updates that cause the secondsToWaitDefault attribute value to be used when determining when to initiate replication sessions. If updateVectorTrigger is set to FALSE, then secondsToWaitDefault will not be used when the replica's updateVector is updated. This implies that some other update will need to be performed to the replica before the updated updateVector will be sent via a replication session. If upateVectorTrigger is set to TRUE, then updates to the updateVector will be used in determining when replication sessions should be initiated. Note that setting secondsToWaitDefault to 0 coupled with updateVectorTrigger to TRUE would cause replication sessions to continually "chase themselves", potentially clogging networks with an infinite loop of replication sessions. This combination SHOULD be prevented in implementations. If not specified, the value for updateVectorTrigger is assumed to be FALSE. 7.2.16. secondsToWaitDefault (2.16.840.1.113719.1.142.4.x NAME 'secondsToWaitDefault' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to the replica before initiating a replication session.' USAGE dSAOperation ) This attribute indicates the number of seconds that a replica should wait after an update is made to the replica before initiating a replication session. If not specified, the value is assumed to be 0. This attribute value is used for updates to all attributes that are NOT specified by either the attrs1 or attrs2 attributes. This attribute is always used for updates made to the replica's updateVector if the updateVectorTrigger attribute is set to TRUE. 7.2.17. secondsToWait1 (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait1' Huber, et al Expires April 2004 [Page 14] LDUP Information Model SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs1 attribute before initiating a replication session.' USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs1 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. 7.2.18. attrReplicationGroup1 ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup1' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait1 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait1 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait1 attribute. When secondsToWait1 seconds have passed since an update to any attribute identified in the attrs1 attribute, a replication session will be initiated. 7.2.19. secondsToWait2 (2.16.840.1.113719.1.142.4.x NAME 'secondsToWait2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'The number of seconds to wait after an update is made to any attributes named in the attrs2 attribute before initiating a replication session.' USAGE dSAOperation ) This attribute is similar to the secondsToWaitDefault attribute in how it is used. This attribute, however, is used to apply only to the attributes listed in the attrs2 attribute. This allows updates to different attributes to cause replication sessions to be initiated either sooner or later than updates made to other attributes. Huber, et al Expires April 2004 [Page 15] LDUP Information Model 7.2.20. attrReplicationGroup2 ( 2.16.840.1.113719.1.142.4.x NAME 'attrReplicationGroup2' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseIgnoreMatch DESC 'the set of attributes that are associated with the secondsToWait2 attribute. When updates are made to any of these attributes on the replica, a replication session will be delayed until after secondsToWait2 seconds have passed.' ) This attribute identifies a set of attributes that are associated with the secondsToWait2 attribute. When secondsToWait2 seconds have passed since an update to any attribute identified in the attrs2 attribute, a replication session will be initiated. 7.2.21. scheduleTimePeriod ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimePeriod' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch SINGLE-VALUE DESC 'the absolute time range over which this time specification is valid.' ) This attribute is patterned after the TimePeriod property identified in RFC 3060 [RFC3060] and [Policy Schema]. See these references for details on the format and interpretation of this attribute. 7.2.22. scheduleMonthOfYearMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleMonthOfYearMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the months of the year during which replication sessions should be performed.' ) This attribute is patterned after the MonthOfYearMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. See these references for details on the format and interpretation of this attribute. 7.2.23. scheduleDayOfMonthMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfMonthMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the month during which replication sessions should be performed.' ) This attribute is patterned after the DayOfMonthMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. See these Huber, et al Expires April 2004 [Page 16] LDUP Information Model references for details on the format and interpretation of this attribute. 7.2.24. scheduleDayOfWeekMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleDayOfWeekMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE DESC 'mask identifying the days of the week during which replication sessions should be performed.' ) This attribute is patterned after the DayOfWeekMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. See these references for details on the format and interpretation of this attribute. 7.2.25. scheduleTimeOfDayMask ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleTimeOfDayMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 EQUALITY caseIgnoreMatch DESC 'mask identifying the times during the day when replication sessions should be initiated.' ) This attribute is patterned after the TimeOfDayMask property identified in RFC 3060 [RFC3060] and [Policy Schema]. See these references for details on the format and interpretation of this attribute. 7.2.26. scheduleLocalOrUtcTime ( 2.16.840.1.113719.1.142.4.x NAME 'scheduleLocalOrUtcTime' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch SINGLE-VALUE DESC 'flag indicating whether or not times in the scheduleTimeOfDayMask are in UTC time or local time.' ) This attribute is patterned after the LocaOrUtcTime property identified in RFC 3060 [RFC3060] and [Policy Schema]. See these references for details on the format and interpretation of this attribute. 7.3. Class Definitions 7.3.1. ReplicationContext ( 2.16.840.1.113719.1.142.6.2.2 NAME 'replicationContext' SUP top AUXILIARY ) The replicationContext auxiliary class, when present on an object, indicates the beginning, or root, of one or more replication Huber, et al Expires April 2004 [Page 17] LDUP Information Model contexts. The replication context is said to be rooted at the entry with the replicationContext auxiliary class in its list of object classes. The root-most entry of a replication context is the entry with the replicationContext auxiliary class in its list of object classes. Characteristics of the replication topology of a replication context are defined in the replicaSubentry sub-entries associated with the replication context. The attribute accessControlPolicyOID has been removed from here, and should be published as an subentry subordinate to the replicationContext, instead. The attribute nameContextCreationTimestamp used here in previous drafts has been eliminated as redundant. The ldapChangeSequenceNumber associated with the replicationContext value in the list of objectclass attribute values serves the same purpose. 7.3.2. replicaSubentry ( 2.16.840.1.113719.1.142.6.3.2 NAME 'replicaSubentry-2' SUP subentry STRUCTURAL MUST ( cn $ replicaURI $ replicaType $ lostAndFoundEntryDN $ replicaOnline ) MAY ( attributeExclusionFilter $ attributeInclusionFilter $ replicaSecondaryURI $ description $ updateVector ) ) Entries of type replicaSubentry MUST be named by their cn attribute as defined in [LDAP Subentry]. A replicationContext may have more than one replicaSubentry. All replicaSubentries MUST be placed just below their associated replicationContext root entries in the directory tree. All replicas MUST hold all replicaSubentries for the replication context. This is required for update vectors. The attributes attributeExclusionFilter and attributeInclusionFilter, if present, govern which entries and attributes from the local naming context are to be sent (or not sent) to the replica named in replicaDN of replica agreements for this replica. The attributeExclusionFilter names attributes which SHOULD NOT be sent. The attributeInclusionFilter names attributes which SHOULD be sent. Huber, et al Expires April 2004 [Page 18] LDUP Information Model The attribute replicaURI contains information in ldapURI format that can be used to contact (i.e., open a connection to) this replica. The replicaSecondaryURI contains the set of ldapURI format addresses that can be used as backup addresses if the replicaURI values cannot be used. The lostAndFoundEntryDN attribute is single-valued attribute that contains the distinguished name of the lost and found entry under which orphaned entries are placed. The replicaOnline attribute is a Boolean attribute which indicates whether or not this replica will supply and/or accept replication sessions. This attribute can be used to prevent replication sessions from being started before replicaAgreement entries have been defined. The attribute description contains a human-readable description of the sub-entry. The attribute updateVector contains a set of ldapChangeSequenceNumbers, one for each of the other replicas for this naming context, which records, from this replicas perspective, the last change event received from the other indicated replica. The subtreespecification attribute of the subentry superior object class is used to define the scope of the replication context. Use of the subtreespecification value SHOULD be limited to the base and components of ChopSpecification portions of this attribute. 7.3.3. replicaAgreement ( ?? NAME 'replicaAgreement' SUP top STRUCTURAL MUST ( cn ) MAY ( description $ replicaDN $ replicationMechanismOID $ replicationStatus $ replicationCredentialsDN $ replicationScheduleDN ) ) If present, entries of this type MUST be placed just below replicaSubentry entries in the directory tree. If replicaAgreements are used, each replica MUST hold all replica agreements for which it is a supplier as well as the entries containing control information referred to by those replica agreements (credentials, schedules, etc.). Name subordination is used to associate a replicaAgreement with the replicaSubentry representing the supplier of changes for all subordinate replication agreements. Huber, et al Expires April 2004 [Page 19] LDUP Information Model Processing of allowable changes to be sent is as follows: 1) the attributeInclusionFilter from the replica subentry defines a set of attributes which SHOULD be sent, less exclusions; 2) the union of attributes excluded by the attributeExclusionFilter from the replicaSubentry and the attributeExclusionFilter from the replicaAgreement defines a set of attributes which SHOULD NOT be sent; 3) the subtraction of attributes which SHOULD NOT be sent by (2) from the attributes which SHOULD be sent by (1) constitute the set of attributes for which changes MAY be sent. The attribute description contains a human-readable description of the sub-entry. The attribute replicaDN of syntax distinguishedName names another sub-entry of type replicaSubentry to whom changes are to be sent. If there is no value for the replicaDN attribute on a replicaAgreement, the replicaAgreement is ignored. Absence of a value may occur briefly when replicas and replica agreements are first being created, or when the replica to which a replica agreement applies is being deleted. The attribute replicationMechanismOID is used to indicate the type of replication protocol that is used between the supplier and consumer. If not specified, the default replication protocol defined in [LDUP Update Replication Protocol] is assumed. The attribute replicationStatus MAY be used to record the most recent result of an attempt to send changes to the replica named in replicaDN, whether success, or if failure, the nature of the problem encountered. The attribute replicationCredentialsDN, if present, names an entry which contains information used to initialize authenticated the LDAP connection between the supplier and consumer. Separating the credentials information from the replicaAgreement itself allows for this information to be placed outside of the replication context. The attribute replicationScheduleDN, if present, names an entry which governs the schedule for replication attempts. If not present, replication MUST be attempted when there are changes to be sent (i.e. a default replica schedule of type replicaEventSchedule is assumed with secondsToWaitDefault=0 and updateVectorTrigger=FALSE). See Section on replicaEventSchedule for more information about these attributes and their meaning. 7.3.4. replicaEventSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaEventSchedule' Huber, et al Expires April 2004 [Page 20] LDUP Information Model SUP top STRUCTURAL MUST ( cn ) MAY ( description $ updateVectorTrigger $ secondsToWaitDefault $ secondsToWait1 $ attrs1 $ secondsToWait2 $ attrs2 ) ) The replicaEventSchedule object class is used to specify when to initiate replication sessions in terms of the time to wait after an update is made to the supplier replica. The attribute cn is used as the naming attribute for the replicaEventSchedule object class. It is thought that replicaEventSchedule entries would be placed below replicaAgreement entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The attribute updateVectorTrigger is a Boolean attribute which indicates whether or not the update of the supplier's updateVector attribute should, itself, be used to trigger replication sessions. Since the updateVector is, itself, an attribute, it has CSNs associated with each of its values. Note that these CSNs may be different from the CSNs that are in the attribute values themselves. Thus, it is possible that the update to the updateVector would, itself, need to be treated as an update to be replicated. Indeed, this is necessary in order for "transitive replication" to work. The secondsToWaitDefault attribute is a non-negative integer value. This value indicates the number of seconds to wait after an update is made before starting a replication session. This value is used for all attributes other than those noted in the attrs1 and attrs2 attributes. The secondsToWait1 attribute is similar to the secondsToWaitDefault attribute. This non-negative integer value is used whenever any attribute listed in the attrs1 attribute is updated. The secondsToWait2 attribute is similar to the secondsToWait1 attribute but is associated with the attrs2 attribute. Note that whenever any of these seconds-to-wait time periods has expired, a replication session should be initiated and the full set of information that needs to be replicated should be sent to the consumer replica. This implies that some information would be replicated before its associated seconds-to-wait time period had expired. Huber, et al Expires April 2004 [Page 21] LDUP Information Model 7.3.5. replicaTimeSchedule ( 2.16.840.1.113719.1.142.6.x.1 NAME 'replicaTimeSchedule' SUP top STRUCTURAL MUST ( cn ) MAY ( description $ scheduleTimePeriod $ scheduleMonthOfYearMask $ scheduleDayOfMonthMask $ scheduleDayOfWeekMask $ scheduleTimeOfDayMask $ scheduleLocalOrUtcTime ) ) The replicaTimeSchedule object class is used to specify when to initiate replication sessions based on a scheduled time basis rather than in relation to when updates are made to the supplier replica. The attribute cn is used as the naming attribute for the replicaTimechedule object class. It is thought that replicaTimeSchedule entries would be placed below replicaAgreement entries but this is not required. The attribute description contains a human-readable description of the sub-entry. The remaining attributes in this object class are patterned after the attributes defined for the policyTimePeriodCondition construct defined in the Policy Core Information Model [RFC3060]. Because the LDAP schema mapping for this portion of the CIM model is not complete at this time, these attributes are defined specifically for this LDUP-related object class. Refer to RFC 3060 for details of the formats for the scheduleTimePeriod, scheduleMonthOfYearMask, scheduleDayOfMonthMask, scheduleDayOfWeekMask, scheduleTimeOfDayMask, and scheduleLocalOrUtcTime attributes. 8. Semantics of the information model The intent of this information model is to allow for useful and expected operation while requiring a minimum amount of data to be specified. In this spirit, replicaAgreement entries are treated as "constraints" on when to initiate replication sessions, not "requirements" on being able to initiate replication sessions. To clarify this concept, two examples are provided in this section. The first example shows the minimal set of information required to get replication going between three replicas: dn: ou=accounting, o=your company objectclass: organizationalUnit objectclass: replicationContext Huber, et al Expires April 2004 [Page 22] LDUP Information Model ou: accounting dn: cn=replica1, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica1 subtreespecification: {} description: replica in location 1 replicaURI: ldap://sys1.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound1, o=your company replicaOnline: TRUE dn: cn=replica2, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica2 subtreespecification: {} description: replica in location 2 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound2, o=your company replicaOnline: TRUE dn: cn=replica3, ou=accounting, o=your company objectclass: subentry objectclass: replicaSubentry-2 cn: replica3 subtreespecification: {} description: replica in location 3 replicaURI: ldap://sys2.yourcompany.com replicaType: 2 lostAndFoundEntryDN: cn=lostAndFound3, o=your company replicaOnline: TRUE With replicaSubentry entries defined as shown in this first example, replication sessions will be initiated by all replicas whenever an update is made to any attribute within any entries in the replicationContext. The default event schedule will be used which indicates that a replication session is initiated immediately after an update is made to a replica. Further, replication sessions would be initiated to ALL OTHER replicas. As this shows, maximal replication is defined using a minimal amount of configuration. The second example shows how replication sessions can be constrained by replicaAgreement entries. This example builds on the data shown in the first example. Assume that the following entries are added to the entries defined in the first example: dn: cn=agreement1->2, cn=replica1, ou=accounting, o=your company objectclass: replicaAgreement cn: agreement1->2 description: Replica agreement constraining replication sessions Huber, et al Expires April 2004 [Page 23] LDUP Information Model from replica 1 to replica 2. replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=agreement1->3, cn=replica1, ou=accounting, o=your company objectclass: replicaAgreement cn: agreement1->3 description: Replica agreement constraining replication sessions from replica 1 to replica 3. replicationScheduleDN: cn=schedule1, cn=replica1, ou=accounting, o=your company replicaDN: cn=replica3, ou=accounting, o=your company dn: cn=schedule1, cn=replica1, ou=accounting, o=your company objectclass: replicaEventSchedule cn: schedule1 description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE dn: cn=agreement2->1, cn=replica2, ou=accounting, o=your company objectclass: replicaAgreement cn: agreement2->1 description: Replica agreement constraining replication sessions from replica 2 to replica 1. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company replicaDN: cn=replica1, ou=accounting, o=your company dn: cn=agreement2->3, cn=replica2, ou=accounting, o=your company objectclass: replicaAgreement cn: agreement2->3 description: Replica agreement constraining replication sessions from replica 2 to replica 3. replicationScheduleDN: cn=schedule2, cn=replica2, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=schedule2, cn=replica2, ou=accounting, o=your company objectclass: replicaEventSchedule cn: schedule2 description: schedule that initiates replication two minutes after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 120 updateVectorTrigger: TRUE dn: cn=agreement3->1, cn=replica3, ou=accounting, o=your company objectclass: replicaAgreement cn: agreement3->1 description: Replica agreement constraining replication sessions Huber, et al Expires April 2004 [Page 24] LDUP Information Model from replica 3 to replica 1. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company replicaDN: cn=replica1, ou=accounting, o=your company dn: cn=agreement3->2, cn=replica3, ou=accounting, o=your company objectclass: replicaAgreement cn: agreement3->2 description: Replica agreement constraining replication sessions from replica 3 to replica 2. replicationScheduleDN: cn=schedule3, cn=replica3, ou=accounting, o=your company replicaDN: cn=replica2, ou=accounting, o=your company dn: cn=schedule3, cn=replica3, ou=accounting, o=your company objectclass: replicaEventSchedule cn: schedule3 description: schedule that initiates replication one minute after any update (including to the updateVector) is made to the replica. secondsToWaitDefault: 60 updateVectorTrigger: TRUE In this example, replication sessions are limited such that they will begin one or two minutes after an update is made to any one replica, depending on the replica on which the update was made. This "constrains" the replication session initiation from the default of "immediate replication" of updates. There are many ways in which the constraints around when to initiate and/or accept replication sessions between two replicas. The information model defined here provides a small set of options. More elaborate policies can be defined and this is left as a future exercise. It is hoped that the work from the Policy workgroup can offer schema that would support the creation of these complex policies. 9. Object Identifier Assignments The LDUP OID prefix is ID ::= OBJECT IDENTIFIER ldup ID ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) novell(113719) novell-internal- OIDS(1) ldup(142) } The OID assignments defined in this document are: Attributes: attributeExclusionFilter ID ::= 2.16.840.1.113719.1.142.4.1 attributeInclusionFilter ID ::= 2.16.840.1.113719.1.142.4.2 Huber, et al Expires April 2004 [Page 25] LDUP Information Model replicationStatus ID ::= 2.16.840.1.113719.1.142.4.3 replicaType ID ::= 2.16.840.1.113719.1.142.4.4 secToWaitClass1 ID ::= 2.16.840.1.113719.1.142.4.5.1 - OBSOLETE secToWaitClass2 ID ::= 2.16.840.1.113719.1.142.4.5.2 - OBSOLETE secToWaitClass3 ID ::= 2.16.840.1.113719.1.142.4.5.3 - OBSOLETE secToWaitClass4 ID ::= 2.16.840.1.113719.1.142.4.5.4 - OBSOLETE secToWaitClass5 ID ::= 2.16.840.1.113719.1.142.4.5.5 - OBSOLETE updateVector ID ::= 2.16.840.1.113719.1.142.4.6 replicaURI ID ::= 2.16.840.1.113719.1.142.4.x replicaSecondaryURI ID ::= 2.16.840.1.113719.1.142.4.x lostAndFoundEntryDN ID ::= 2.16.840.1.113719.1.142.4.x replicaOnline ID ::= 2.16.840.1.113719.1.142.4.x replicaDN ID ::= 2.16.840.1.113719.1.142.4.x replicationMechanismOID ID ::= 2.16.840.1.113719.1.142.4.x replicationCredentialsDN ID ::= 2.16.840.1.113719.1.142.4.x replicationScheduleDN ID ::= 2.16.840.1.113719.1.142.4.x updateVectorTrigger ID ::= 2.16.840.1.113719.1.142.4.x secondsToWaitDefault ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait1 ID ::= 2.16.840.1.113719.1.142.4.x attrReplicationGroup1 ID ::= 2.16.840.1.113719.1.142.4.x secondsToWait2 ID ::= 2.16.840.1.113719.1.142.4.x attrReplicationGroup2 ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimePeriod ID ::= 2.16.840.1.113719.1.142.4.x scheduleMonthOfYearMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfMonthMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleDayOfWeekMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleTimeOfDayMask ID ::= 2.16.840.1.113719.1.142.4.x scheduleLocalOrUtcTime ID ::= 2.16.840.1.113719.1.142.4.x supportedReplicationProtocols ID ::= 2.16.840.1.113719.1.142.4.x replicaContextRoots ID ::= 2.16.840.1.113719.1.142.4.x replicaSubentries ID ::= 2.16.840.1.113719.1.142.4.x Object Classes: eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE nameContext ID ::= 2.16.840.1.113719.1.142.6.2.1 - OBSOLETE replicaSubentry ID ::= 2.16.840.1.113719.1.142.6.3.1 - OBSOLETE replicaAgreementSubentry ID ::= 2.16.840.1.113719.1.142.6.4.1 – OBSOLETE replicationContext ID ::= 2.16.840.1.113719.1.142.6.2.2 replicaSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.3.2 replicaAgreementSubEntry-2 ID ::= 2.16.840.1.113719.1.142.6.4.2 - OBSOLETE eventScheduledSubentry ID ::= 2.16.840.1.113719.1.142.6.1 - OBSOLETE replicaEventSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 Huber, et al Expires April 2004 [Page 26] LDUP Information Model replicaTimeSchedule ID ::= 2.16.840.1.113719.1.142.6.x.1 replicaAgreement ID ::= TBD Note: Object Class OIDs have version numbers, Attribute OIDs don't. 10. Security Considerations Many of the attributes and object classes described in this document should be considered "security sensitive", and protected from unintended modification by LDAP servers. Generally, creating Naming Contexts, Replicas and Replica Agreement entries should only be allowed by directory administrators who are authorized to do so. The values of attributes defined here are intended to control the behavior of the directory service agents, themselves. Unintended modification of their values may result in incomplete replication of data (if ldapSearchFilter or attributeExclusionFilter are changed), inappropriate disclosure of information (if attributeInclusionFilter is changed), or updates may be lost (if updateVector is changed). To avoid depending to much on the ldapAccessPoint values for other replicas, connections between LDAP servers for the purpose of replication MUST ALWAYS be authenticated using an authentication mechanism appropriate for the nature of information to be exchanged. References [LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, "An Abstract Model of LDAP Replication", Internet draft, draft-ietf-ldup-model- 08.txt, March 2003. [LDUP MRM] – R. Moats, R. Huber, J. McMeeking, “Mandatory LDAP Replica Management,” Internet Draft, draft-ietf-ldup-mrm-02.txt, March 2003. [LDAP Subentry] – K. Zeilenga, Stephen Legg, "Subentries in LDAP", Internet draft, draft-zeilenga-ldap-subentry-07.txt, August 2002. [LDUP Update Protocol] – J. McMeeking, "The LDUP Replication Update Protocol", Internet Draft, draft-ietf-ldup-protocol-04.txt, March 2003. [Policy Schema] - J. Strassner, B. Moore, R. Moats, E. Ellesson, "Policy Core LDAP Schema", Internet draft, draft-ietf-policy-core- schema-16.txt, October 2002. [RFC822] – D. Crocker, "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", August 1982, RFC 822. Huber, et al Expires April 2004 [Page 27] LDUP Information Model [RFC2251] – M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", December 1997, RFC 2251. [RFC2252] – M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", December 1997, RFC 2252. [RFC2255] – T. Howes, M. Smith, “The LDAP URL Format”, December 1997, RFC 2255. [RFC2596] - 2596 M. Wahl, T. Howes, “Use of Language Codes in LDAP”, May 1999, RFC 2596. [RFC2820] – E. Stokes, D. Byrne, B. Blakley, P. Behara, “Access Control Requirements for LDAP,” May 2000, RFC 2820. [RFC3060] – B. Moore, E. Ellesson, J. Strassner, A. Westerinen, "Policy Core Information Model – Version 1 Specification", February 2001, RFC 3060. [RFC3384] - E. Stokes, R. Weiser, R. Moats, R. Huber, "Lightweight Directory Access Protocol (version 3) Replication Requirements", October 2002, RFC 3384. [X518] - ITU-T Recommendation X.518 (1997) | ISO/IEC 9594-4:1998, Information Technology – Open Systems Interconnection – The Directory: Procedures for Distributed Operation. [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, Information technology – Abstract Syntax Notation One (ASN.1): Specification of Basic Notation. 11. Copyright Notice Copyright (C) The Internet Society (2001). 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 implementation 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. Huber, et al Expires April 2004 [Page 28] LDUP Information Model 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. 12. Acknowledgements The authors would like to thank Ed Reed and Tim Han, the authors of the original infomod draft, for all their work. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Authors' Addresses Richard Huber AT&T Laboratories Email: rvh@att.com John McMeeking IBM Email: jmcmeek@us.ibm.com Ryan Moats Lemur Networks, Inc. Email: rmoats@lemurnetworks.net LDUP Mailing List: ietf-ldup@idc.org Huber, et al Expires April 2004 [Page 29] --------------050608070409010502060409-- From owner-ietf-ldup@mail.imc.org Wed Oct 22 10:59:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13442 for ; Wed, 22 Oct 2003 10:59:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEnoI7044754 for ; Wed, 22 Oct 2003 07:49:50 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MEnoiA044752 for ietf-ldup-bks; Wed, 22 Oct 2003 07:49:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from echt.caledonia.net (echt.caledonia.net [216.98.200.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MEnmI7044739 for ; Wed, 22 Oct 2003 07:49:49 -0700 (PDT) (envelope-from capple@dsi-consulting.net) Received: from D7ST2111 (dhcp64-134-214-101.sptc.dca.wayport.net [64.134.214.101]) by echt.caledonia.net; Wed, 22 Oct 2003 08:49:20 -0600 Reply-To: From: "Chris Apple" To: "'Ryan Moats'" , Subject: RE: submission: draft-ietf-ldup-infomod-08.txt Date: Wed, 22 Oct 2003 10:49:00 -0400 Organization: DSI-Consulting, Inc. Message-ID: <001e01c398ab$a94fe180$65d68640@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3F96843C.8000404@lemurnetworks.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John and I are sorting through how to cycle/stage the last calls for various documents. Thanks for getting the document revised in time for the meeting. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Ryan Moats Sent: Wednesday, October 22, 2003 9:21 AM To: internet-drafts@ietf.org; ietf-ldup@imc.org Subject: submission: draft-ietf-ldup-infomod-08.txt To the I-D editor: Attached is draft-ietf-ldup-infomod-08.txt for the repository. To LDUP: Attached is draft-ietf-ldup-infomod-08.txt, ready for last call. As such, we've extracted the document changes section and place it here for reference. John and Chris, please schedule a last call when you can. Ryan Moats (for the authors) ===================Recent document changes Changes in this version (-08) - Explicitly change replicaAgreement to not be a subentry. - Explicitly allow multiple replicaSubentries per replicaContext - Added replicaDN to examples. - Remove discussion of "Primary" replica. - Clarify information that must be present in all replicas (replicaSubentries) and what replicaAgreements and associated information must be present in a replica. Changes made to previous versions - Fixed OID values to have correct prefix: 2.16.840.1.113719.1.142 - Fixed formatting to avoid strange single quote characters in text formatted file - Changed name of attrs1 and attrs2 to attrReplicationGroup1 and attrReplicationGroup2 - Made obsolete timeScheduledSubentry and eventScheduledSubentry - Re-based replicaSubEntry and other object classes on subentry schema from draft-zeilenga-ldap-subentry-00.txt - Clarified that root DSE attribute replicaSubentries should be automatically updated on both add and delete of these entries - Made obsolete replicaSubEntry and replicaAgreementSubentry object classes - Defined replacement object classes replicaSubEntry2 and replicaAgreementSubentry2 - Defined replicaEventSchedule and replicaTimeSchedule object classes and associated attributes - Defined attributes that must appear in the server's root DSE entry as part of the LDUP information model - Many editorial fixes - Clarified the notion that the updateVector is a replicated attribute and thus, itself, has CSN information for its attribute values - Introduced the notion that replicaAgreementSubentry entries represent constraints to what is, by default, "immediate" replication session initiation - LDAP Schedule Subentry definition is defined. - LDAP Access Point removed in favor of just using the DN of the server holding the replica (so a new syntax isn't required). - LDAP Change Sequence Number syntax eliminated in favor of just calling it a CaseIgnoreString, so new comparison rules aren't required. - Deleted ldapSearchFilter definition from here. Sparse replicas is deferred. Might sparse be supported for single-master configurations (read-only, of course). - Fractional are okay in multi-master configurations, but again, only on read-only replicas. - Changed the naming convention upper-lower case usage to look less weird.- Consistency discussion - Schema document must clearly indicate that clients can and should inspect the replica subentries to understand the single-master/multi-master nature of the naming context to which they're talking. - The paradigm change, to distributed data, needs to be exhaustively discussed in the profile documents. How old applications which assume single-master behave or misbehave in a multi-master environment is critical to make clear. Draw examples from SMP pre-emptive programming practices, from DNS vs. host file models, etc. From owner-ietf-ldup@mail.imc.org Fri Oct 24 10:59:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06446 for ; Fri, 24 Oct 2003 10:59:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OEoTI7081932 for ; Fri, 24 Oct 2003 07:50:29 -0700 (PDT) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OEoTNn081931 for ietf-ldup-bks; Fri, 24 Oct 2003 07:50:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OEoOI7081920 for ; Fri, 24 Oct 2003 07:50:25 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05178; Fri, 24 Oct 2003 10:50:15 -0400 (EDT) Message-Id: <200310241450.KAA05178@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-08.txt Date: Fri, 24 Oct 2003 10:50:14 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Replication Information Model Author(s) : R. Huber, J. McMeeking, R. Moats Filename : draft-ietf-ldup-infomod-08.txt Pages : 32 Date : 2003-10-23 [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-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-infomod-08.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-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24103557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-infomod-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-infomod-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103557.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Oct 27 09:22:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15358 for ; Mon, 27 Oct 2003 09:22:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REGDI7052022 for ; Mon, 27 Oct 2003 06:16:13 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9REGDV9052021 for ietf-ldup-bks; Mon, 27 Oct 2003 06:16:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REGCI7052015 for ; Mon, 27 Oct 2003 06:16:12 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14162; Mon, 27 Oct 2003 09:16:02 -0500 (EST) Message-Id: <200310271416.JAA14162@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-urp-08.txt Date: Mon, 27 Oct 2003 09:16: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 Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-08.txt Pages : 32 Date : 2003-10-24 This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-08.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-urp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24160642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24160642.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Oct 27 09:23:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15438 for ; Mon, 27 Oct 2003 09:23:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REGAI7052013 for ; Mon, 27 Oct 2003 06:16:10 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9REGAWc052012 for ietf-ldup-bks; Mon, 27 Oct 2003 06:16:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REG9I7052007 for ; Mon, 27 Oct 2003 06:16:09 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14144; Mon, 27 Oct 2003 09:15:59 -0500 (EST) Message-Id: <200310271415.JAA14144@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-urp-08.txt Date: Mon, 27 Oct 2003 09:15:58 -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 Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-08.txt Pages : 32 Date : 2003-10-24 This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-08.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-urp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24160642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24160642.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Oct 27 17:10:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19468 for ; Mon, 27 Oct 2003 17:10:50 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLr3I7076408 for ; Mon, 27 Oct 2003 13:53:03 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLr3NP076407 for ietf-ldup-bks; Mon, 27 Oct 2003 13:53:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLr0I7076399 for ; Mon, 27 Oct 2003 13:53:01 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16214; Mon, 27 Oct 2003 16:52:50 -0500 (EST) Message-Id: <200310272152.QAA16214@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-urp-08.txt Date: Mon, 27 Oct 2003 16:52:50 -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 Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-08.txt Pages : 32 Date : 2003-10-24 This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-08.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-urp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171320.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Oct 27 17:19:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21245 for ; Mon, 27 Oct 2003 17:19:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMAMI7077676 for ; Mon, 27 Oct 2003 14:10:23 -0800 (PST) (envelope-from owner-ietf-ldup@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RMAMIi077675 for ietf-ldup-bks; Mon, 27 Oct 2003 14:10:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ldup@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMAII7077637 for ; Mon, 27 Oct 2003 14:10:18 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19213; Mon, 27 Oct 2003 17:10:07 -0500 (EST) Message-Id: <200310272210.RAA19213@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-urp-08.txt Date: Mon, 27 Oct 2003 17:10:07 -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 Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-08.txt Pages : 32 Date : 2003-10-24 This document describes the procedures used by Lightweight Directory Access Protocol (LDAP) directory servers or X.500 directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service, using the LDAP Duplication/Replication/Update protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-urp-08.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-urp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171320.I-D@ietf.org> --OtherAccess-- --NextPart--