From owner-ietf-ldup@mail.imc.org Fri Feb 1 12:36:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05236 for ; Fri, 1 Feb 2002 12:36:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11HGME10505 for ietf-ldup-bks; Fri, 1 Feb 2002 09:16:22 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11HGL310498 for ; Fri, 1 Feb 2002 09:16:21 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA138226 for ; Fri, 1 Feb 2002 12:12:59 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11HG1O183344 for ; Fri, 1 Feb 2002 12:16:01 -0500 From: "John McMeeking" Subject: March IETF meeting - when is LDUP? To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 1 Feb 2002 11:16:01 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 02/01/2002 11:16:02 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBE1C0DFCD10708f9e8a93df938690918c09BBE1C0DFCD1070" Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=09BBE1C0DFCD10708f9e8a93df938690918c09BBE1C0DFCD1070 Content-type: text/plain; charset=US-ASCII Is the LDUP WG having a session at the March IETF meeting? I don't see it on the agenda. John McMeeking --0__=09BBE1C0DFCD10708f9e8a93df938690918c09BBE1C0DFCD1070 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Is the LDUP WG having a session at the March IETF meeting? I don't see it on the agenda.


John McMeeking
--0__=09BBE1C0DFCD10708f9e8a93df938690918c09BBE1C0DFCD1070-- From owner-ietf-ldup@mail.imc.org Sat Feb 2 11:00:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04971 for ; Sat, 2 Feb 2002 11:00:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g12FheD17344 for ietf-ldup-bks; Sat, 2 Feb 2002 07:43:40 -0800 (PST) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g12Fhd317340 for ; Sat, 2 Feb 2002 07:43:39 -0800 (PST) Received: from D7ST2111 ([141.158.246.245]) by out009.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020202154335.IQTF11848.out009.verizon.net@D7ST2111>; Sat, 2 Feb 2002 09:43:35 -0600 Reply-To: From: "Chris Apple" To: "'John McMeeking'" , Subject: RE: March IETF meeting - when is LDUP? Date: Sat, 2 Feb 2002 10:42:06 -0600 Message-ID: <002501c1ac08$8d3f0d40$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0026_01C1ABD6.42A49D40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal 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_0026_01C1ABD6.42A49D40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0027_01C1ABD6.42A49D40" ------=_NextPart_001_0027_01C1ABD6.42A49D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Its on my ToDo list to send in a meeting slot request this coming week. Cut-off for requesting a meeting slot is Feb 22, 2002..hopefully, we'll see the slot show up on the agenda by the end of this coming week. Chris Apple christopher.apple@verizon.net -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of John McMeeking Sent: Friday, February 01, 2002 11:16 AM To: ietf-ldup@imc.org Subject: March IETF meeting - when is LDUP? Is the LDUP WG having a session at the March IETF meeting? I don't see it on the agenda. John McMeeking ------=_NextPart_001_0027_01C1ABD6.42A49D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Its on=20 my ToDo list to send in a meeting slot request this coming week. Cut-off = for=20 requesting a meeting slot
is Feb=20 22, 2002..hopefully, we'll see the slot show up on the agenda by the end = of this=20 coming week.

Chris = Apple

christopher.apple@verizon.net

-----Original Message-----
From:=20 owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] = On=20 Behalf Of John McMeeking
Sent: Friday, February 01, 2002 = 11:16=20 AM
To: ietf-ldup@imc.org
Subject: March IETF = meeting -=20 when is LDUP?

Is the LDUP WG having a session at the March IETF meeting? I don't = see it=20 on the agenda.


John = McMeeking

------=_NextPart_001_0027_01C1ABD6.42A49D40-- ------=_NextPart_000_0026_01C1ABD6.42A49D40 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0026_01C1ABD6.42A49D40-- From owner-ietf-ldup@mail.imc.org Wed Feb 6 15:07:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00144 for ; Wed, 6 Feb 2002 15:07:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16Jteo22184 for ietf-ldup-bks; Wed, 6 Feb 2002 11:55:40 -0800 (PST) Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Jtd322179 for ; Wed, 6 Feb 2002 11:55:39 -0800 (PST) Received: from CHRIS-H.opengroup.org (dhcp192-153-166-45.rdg.opengroup.org [192.153.166.45]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g16JtLg13720; Wed, 6 Feb 2002 19:55:21 GMT Message-Id: <5.1.0.14.1.20020206192832.06778cc0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Feb 2002 19:37:04 +0000 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org, ietf-ldapbis@OpenLDAP.org, ldap@umich.edu From: Chris Harding Subject: Directory Interoperability Forum Hosts its 2nd Plugfest, February 26 and 27, 2002 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_121644966==_.ALT" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_121644966==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi - Test your applications for Works with LDAP 2000 compliance! The DIF's 2nd Plugfest offers you the opportunity to test your applications for interoperability with servers from leading vendors such as Oracle, Novell, IBM and more, all at the time and the same location. At our last Plugfest, 8 leading server vendors provided hardware and HP, PeopleSoft and SAP were among the 20 applications that tested and received the Open Group's Works with LDAP certification. Expand the market for your applications by providing prospects with guaranteed interoperability in a host of infrastructure environments. This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The cost to participate is $495 dollars, which is waived when you choose to brand your application as Works with LDAP. More detailed information about this Plugfest and Works with LDAP certification is available at the DIF website at http://www.opengroup.org/dif/. Register on the web, or contact me. I look forward to seeing you, Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== The Open Group Conference - "Managing The Mobile Workforce" Paris, France, 8-12 April 2002 http://www.opengroup.org/paris2002 ======================================================================== --=====================_121644966==_.ALT Content-Type: text/html; charset="us-ascii"  Hi -

Test your applications for Works with LDAP 2000 compliance!

The DIF's 2nd Plugfest offers you the opportunity to test your applications for interoperability with servers from leading vendors such as Oracle, Novell, IBM and more, all at the time and the same location. At our last Plugfest, 8 leading server vendors provided hardware and HP, PeopleSoft and SAP were among the 20 applications that tested and received the Open Group's Works with LDAP certification.

Expand the market for your applications by providing prospects with guaranteed interoperability in a host of infrastructure environments.
 
This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The cost to participate is $495 dollars, which is waived when you choose to brand your application as Works with LDAP.

More detailed information about this Plugfest and Works with LDAP certification is available at the DIF website at http://www.opengroup.org/dif/. Register on the web, or contact me.

I look forward to seeing you,


Regards,

Chris
+++++

========================================================================
           Dr. Christopher J. Harding
  T H E    Executive Director for the Directory Interoperability Forum
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:c.harding@opengroup.org Phone:  +44 118 950 8311 x2262
           WWW: http://www.opengroup.org Mobile: +44 774 063 1520
========================================================================
The Open Group Conference - "Managing The Mobile Workforce"
Paris, France, 8-12 April 2002
http://www.opengroup.org/paris2002
========================================================================
--=====================_121644966==_.ALT-- From owner-ietf-ldup@mail.imc.org Thu Feb 14 15:19:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08699 for ; Thu, 14 Feb 2002 15:19:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EK4Av19553 for ietf-ldup-bks; Thu, 14 Feb 2002 12:04:10 -0800 (PST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EK48319547 for ; Thu, 14 Feb 2002 12:04:08 -0800 (PST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA22482; Thu, 14 Feb 2002 21:02:55 +0100 (MET) Date: Thu, 14 Feb 2002 09:07:35 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: rmoats@lemurnetworks.net, rweiser@trustdst.com, estokes@tivoli.com, rvh@att.com cc: Allison Mankin , Ned Freed , ietf-ldup@imc.org Subject: Comments from IESG on draft-ietf-ldup-replica-req-10.txt Message-ID: <7629577.1013677655@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit + It requires minimum mandatory-to-implement encryption, but fails to do same for integrity + It needs a statement that avoidance of congestion and over-chattiness of the replication protocol must be considered in the design. Please send comments, and suggested text to change. paf From owner-ietf-ldup@mail.imc.org Mon Feb 18 08:44:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02758 for ; Mon, 18 Feb 2002 08:44:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1IDRIr14451 for ietf-ldup-bks; Mon, 18 Feb 2002 05:27:18 -0800 (PST) Received: from tconl91223.tconl.com ([63.127.165.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1IDRE314447 for ; Mon, 18 Feb 2002 05:27:14 -0800 (PST) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id g1IEQ0002397; Mon, 18 Feb 2002 08:26:00 -0600 Date: Mon, 18 Feb 2002 08:25:59 -0600 From: Ryan Moats To: internet-drafts@ietf.org Cc: ietf-ldup@imc.org, Richard V Huber , John McMeeking Subject: draft-ietf-ldup-mrm-01 Message-ID: <20020218082559.B1479@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To the I-D editor: please insert this in place of draft-ietf-ldup-mrm-00.txt LDUP working group- Here's -01 of the MRM draft. There are several places in the draft where there are outstanding WG issues. I've pulled them all here, some with our thoughts. This is a superset of the mail Rick posted and has some of the reasons why we were asking... 1. Sections 4.2 and 4.5 shows some of the reasons for wanting a subtreeSpecificationDN. Without it, finding entries and areas of replication require a matching rule for subtreeSpecification. 2. The approach of Section 4.4 for creating the server entry for an area of replication implies that InfoMod needs to explicitly define replicaOnline as DSA specific with a default value of FALSE. 3. In section 4.7, we have asked Info Mod authors if there a reason to allow a replication agreement to be created without a replicaDN? The Information Model explicity allows this, but the effect is to cause the agreement to be ignored. We think the attribute should be a MUST, and further, that it should not be modifiable. 4. Working on section 5.12, led to the following discussion that we are looking for more input on: RVH - Can the schedules of a different area of replication be referenced? Is there something that says that the schedules must be IN the area of replication they control? JAM - I think that schedules and credentials need only be accessible to the replicas that use them. That said, they are defined as subentries, and ought at least be under a replicaSubentry. RDM - If this means that there are no reusable schedules and credentials, I think that is a Bad Thing. 5. Also in Section 5.12, there is a question on whether the steps of 5.12 need to be performed on each server containing a replica of the parent area of replication: RVH - Why? - Aren't all of the items changed WITHIN the original area of replication? So won't they replicate as long as step 4 is done last? JAM - Once the new area of replication is defined on one server, it quite likely defines the bounds of the superior. That means that any further activity in the new area is replicated according to the subentries and agreements defined for it - initially none. It would be cleaner, in some respects, though, it would be nice if defining the new area of replication cloned the subentries, agreements, etc. from the superior and was replicated. RDM - If that isn't covered in info-mod, I think it probably should be. 6. The steps of Section 5.24 imply the need to ensure that the master replicates changes to the fail-over server before replicating a change to other servers. Otherwise, a replica may have changes that have not been replicated to the fail-over server. This can be accomplished by requiring that if writable replica notes that there is only one other replica with replication agreements defined, the supplier should replicate to that server first. 7. In addition, step 2 of Section 5.24 implies that a replica that acts as a supplier to no other server need only keep sufficient state information to satisfy idempotency and conflict resolution. Ryan (for the authors) =================== INTERNET DRAFT Mandatory LDAP Replica Management February 2002 Internet-Draft Ryan Moats LDAP Duplication/Replication/Update Lemur Networks, Inc. Protocols WG Rick Huber Intended Category: Standard AT&T Laboratories Expires August 2002 John McMeeking IBM February 2002 Mandatory LDAP Replica Management Filename: draft-ietf-ldup-mrm-01.txt 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/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract The goal of standards for LDAP replication is to allow interoperable replication among products from many different vendors. Defining the mechanism to move data among replicas is a necessary part of this work, but management of the replicated environment must also be standardized for replication to be truly interoperable. This document presents the replication management functions that must be performed. Whenever possible, these functions are defined in terms of existing LDAP functionality using existing LDAP operations and existing data definitions. In some cases, changes or additions to the existing model are required, and specifications for these changes are included in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Moats, et al Expires August 2002 [Page 1] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 1 Table of Contents Status of this Memo...................................................1 Abstract..............................................................1 1 Table of Contents ..................................................2 2 Introduction .......................................................3 3 Administrative Precursors ..........................................3 4 Operational "Atoms" ................................................4 4.1 Add area of replication to a server ..............................4 4.2 Delete area of replication from a server .........................5 4.3 Copy base of area of replication between servers .................5 4.4 Create server entry for an area of replication ...................5 4.5 Delete server entry from an area of replication ..................6 4.6 Modify replica ...................................................6 4.6.1 Change Replica Type ............................................6 4.6.2 Change Between Full/Partial Replica ............................7 4.6.3 Change Replica URI for one server for one area of replication ..7 4.7 Add Replication Agreement ........................................7 4.8 Delete Replication Agreement .....................................8 4.9 Modify Replication Agreement .....................................8 4.10 Suspend Replication .............................................9 4.11 Resume Replication ..............................................9 4.12 Trigger an Immediate Replica Cycle ..............................9 4.13 Immediately Terminate a Replica Cycle ..........................10 4.14 Search with Meta-Data ..........................................11 4.15 Changing Replication Meta-Data .................................11 4.15.1 Add with Meta-Data ...........................................11 4.15.2 Delete with Meta-Data ........................................12 4.15.3 Modify with Meta-Data ........................................12 4.16 Write-Unwriteable Control ......................................12 5 Common Tasks ......................................................13 5.1 Add a new replica to an existing replica group ..................13 5.1.1 Large area of replication support .............................14 5.2 Verify replication information is present between two servers ...15 5.2.1 Verify that replication objects exist .........................15 5.2.2 Verify that it is valid for replication to occur between these servers ............................................................16 5.3 Start replication between two servers ...........................17 5.4 Suspend Replication activity on one area of a server ............17 5.5 Suspend Replication activity on all areas of a server ...........17 5.6 Restart Replication activity on one area of a server ............17 5.7 Restart Replication activity on all areas of a server ...........17 5.8 Halt replication ................................................18 5.9 List status of a particular area of replication on a given server .............................................................18 5.9.1 Local Replica On-Line .........................................18 5.9.2 Remote Replicas On-Line .......................................18 5.9.3 Check Status of Outward Replication ...........................18 5.9.4 Check Status of Incoming Replication ..........................19 5.10 List all areas of replication defined on a given server and their status .......................................................19 5.11 Restore a server and replication agreements after a server crash ..............................................................19 5.11.1 Recent Backup is Available ...................................19 5.11.2 Backup is Not Available ......................................20 5.12 Split an Area of Replication ...................................20 5.13 Move an existing area of replication to a new server ...........21 5.14 Join two Areas of Replication ..................................21 5.14.1 Preconditions ................................................21 Moats, et al Expires August 2002 [Page 2] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 5.14.2 Procedure ....................................................21 5.14.3 Server requirements ..........................................21 5.15 Stop Replicating an Area of Replication ........................22 5.16 Convert a read-only replica to an updateable replica ...........22 5.17 Convert an updateable replica to a read-only replica ...........23 5.18 Postpone a Replica Cycle to a Later Time .......................23 5.19 Examine Replication Audit History on a Server ..................23 5.20 Compare Two Replicas on Two Servers for Differences ............23 5.21 Fix an Entry Without Triggering Replication ....................24 5.22 Check Reported Schema Mismatches Discovered During Replication .25 5.23 Adding a new directory server to a replica group and initializing the contents ..........................................25 5.24 Restore from the master failure in a single-master system ......25 6 Formal Specifications .............................................26 6.1 New/Modified Object Classes .....................................26 6.2 New/Modified Attributes .........................................26 6.3 New/Modified Extended Operations ................................26 6.4 New/Modified Replication Primitives .............................26 6.5 New/Modified Controls ...........................................26 7 Security Considerations ...........................................26 8 Acknowledgements ..................................................27 9 References ........................................................27 Authors' Addresses:..................................................28 Full Copyright Statement.............................................28 2 Introduction In the LDAP replication architecture [Arch], the LDAP servers and replication agreements between them are represented by entries in the directory tree, as part of the replicated naming context. The LDAP replication information model [InfoMod] describes the contents of these entries. Replication management entries, such as replicaSubentries or replication agreements, can be altered on any updateable replica using standard LDAP operations [RFC2251]. These entries are explicitly included in the directory entries governed by any agreement associated with this area of replication. As a result, all servers with a replica other replicas of that area of replication and associated agreements. The deployment and maintenance of a replicated directory network involves the creation and management of the replicas themselves and associated replication control information (e.g. replicationSubentries and replication agreements). This document outlines the administrative actions necessary to create and maintain replication agreements. Typically, administrative tools will guide the administrator and facilitate these actions. 3 Administrative Precursors In this document the term "administrative user" refers to an identity that will be performing replication configuration by binding to and invoking operations on directory servers. Most LDAP server implementations have the concept of a superuser or power user, however this need not be the same as the administrative user, so long as the administrative user has been granted appropriate privileges. The administrative user MAY be running as an autonomous process, and MUST be capable of securely maintaining its own credentials. of an area of replication will have access to information about all Moats, et al Expires August 2002 [Page 3] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 Deployments SHOULD create an administrative user identity that is granted access to all servers holding a replica of a naming context to perform the procedures described below, in particular to read the root DSE, the replicationContext prefix entry and all subordinate subentries. The administrative user who will be viewing or modifying the replication status MUST have already been provided with and established in the directory server or servers appropriate authentication credentials and authorization rights to retrieve attributes and invoke DIT modification operations that are beyond the ability of the 'average' directory user. Through out-of-band means one of the following will have occurred: 1. the administrative user and the directory server have agreed upon a shared secret which the administrator will use to authenticate itself, or 2. the administrative user will have a certificate (or other network credential) that can be validated by the directory server. Note that the secret in the first case need not be held by the directory server itself but could be maintained by an authentication service trusted by the directory server. 4 Operational "Atoms" The following operational atoms are used to build up more complex tasks in section 5. Most of these operational "atoms" make the following assumptions: Through prior LDAP or out-of-band means the administrative user MUST have been granted the following access control permissions to the directory in order to establish replication: - Create the naming context prefix entry - Create subentries immediately below the naming context prefix entry In several sections below, we refer to "source" and "target" servers. The "source" server is a server that already holds a copy of the area of replication. It may already be replicating that area with other servers. The "target" server does not currently hold a copy of the area of replication. The "target" is being added to the replica-group. The LDUP Architecture [Arch] allows for read-only replicas. Setting up and maintaining a read-only replica will sometimes require that the administrator create or modify data on the read-only replica. In this case, the Write-Unwriteable control (Section 4.16) should be used. 4.1 Add area of replication to a server The client SHOULD invoke a ModifyRequest in which the object field is the context prefix of the replication context, and the modification list consists of a single item to add the value replicationContext to the attribute objectClass. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. Should an error occur at this point, the server is in an inconsistent state and needs to be fixed. Moats, et al Expires August 2002 [Page 4] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 After this step is completed, the server will begin storing change information for this area of replication. 4.2 Delete area of replication from a server On the target server, the client SHOULD invoke a SearchRequest to find all replicaSubentry objects which refer to the area of replication: 1. Retrieve all the values of the replicaContextRoots attribute in the root DSE of the server. Each value is the distinguished name of the base entry of the base entry of a Replication Context held on the server. 2. Perform a one-level LDAP search in each replicaContextRoot for objects of class replicaSubentry whose replicaURI attribute points to the given server (e.g. use a filter of "(&(objectclass=replicaSubentry-2)(replicaURI=ldap://thisserver))") where "thisserver" is the DNS name of the given server. The client then examines the subtreeSpecifications to determine which one it wants and then deletes all replicaSubentries with that subtreeSpecification. If any of the DelRequests fail, the area of replication has not been completely removed. After this step is completed, the target server will no longer replicate this area of replication nor will it record changes for later replication. However, the other servers in the replica group for this area will still have a replicaSubentry for the given server, and this should be cleaned up. WG Issue: This is a reason for the subtreeSpecification issue. If it were a DN, this would be much easier. Otherwise, we're going to need a matching rule for subtreeSpecification. 4.3 Copy base of area of replication between servers In this section, the "target server" is the server on which the client has just modified the root DSE. The client MUST separately contact another server, one that already holds a copy of this replication context, and issue a SearchRequest on that server in which the baseObject is the DN of the base of the area of replication, the scope baseObject, the filter "(objectClass=*)" and the attributes list {"*", entryUuid}. If the client cannot obtain the single entry at this point, the procedure will fail. Now that it has the entry, the client SHOULD invoke an AddWithMetaData (see 4.15.1) on the target server with entry set to the DN of the base of the area of replication and attributes the same list as obtained in the previous search. If the server returns a resultCode other than success, it is an error, and the server will be in an inconsistent state. 4.4 Create server entry for an area of replication Each server needs to have in its copy of the area of replication a replicaSubentry for each of the servers involved in replicating that Moats, et al Expires August 2002 [Page 5] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 area before replication can be started. These entries MUST have the following attributes: 1. objectclass, with values top, ldapSubentry and replicaSubentry 2. cn 3. replicaURI 4. replicaType and MAY contain other attributes, as described in the Information Model [InfoMod]. WG Issue: This means that InfoMod needs to explicitly define replicaOnline as DSA specific with a default value of FALSE. 4.5 Delete server entry from an area of replication On the target server, the client SHOULD invoke a SearchRequest to find all replicaSubentry objects which refer to the area of replication: 1. Retrieve all the values of the replicaContextRoots attribute in the root DSE of the server. Each value is the distinguished name of the base entry of the base entry of a Replication Context held on the server. 2. Perform a one-level LDAP search in each replicaContextRoot for objects of class replicaSubentry whose replicaURI attribute points to the given server (e.g. use a filter of "(&(objectclass=replicaSubentry- 2)(replicaURI=ldap://thisserver))") where "thisserver" is the DNS name of the given server. The client then examines the subtreeSpecifications and the replicaURI to determine which one(s) it wants and then deletes all replicaSubentries with that proper subtreeSpecification and replicaURI. If any of the DelRequests fail, the area of replication has not been completely removed. WG Issue: This is another reason for the subtreeSpecification issue. If it were a DN, this would be much easier. Otherwise, we're going to need a matching rule for subtreeSpecification. 4.6 Modify replica 4.6.1 Change Replica Type Note: This section covers only the simple protocol operation to change the replica type. Section 5.16 covers the full set of operations for converting from a ReadOnly to an Updateable replica. The client SHOULD invoke a ModifyRequest with the Write-Unwriteable control (Section 4.16) in which the object field is the replicationSubentry, and the modification list consists of a single item to change the value of the attribute replicaType. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. Moats, et al Expires August 2002 [Page 6] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 4.6.2 Change Between Full/Partial Replica Note: This section currently discusses how to change between fractional and full replication. Once the information model supports sparse replication, it will need to be added here. This section only discusses only the simple LDAP protocol operations to change between full and partial replicas. Additional actions are discussed in Section 5.15. To switch from fractional to full replication, a client SHOULD invoke a ModifyRequest with the Write-Unwriteable control (Section 4.16) in which the object field is the replicaSubentry, and the modification list consists of two items: one to remove the attribute attributeExclusionFilter and the other to remove the attribute attributeInclusionFilter. If the server responds with a resultCode other than noSuchAttribute or success then an error has occurred. To switch from full to fractional replication, a client SHOULD invoke a ModifyRequest with the Write-Unwriteable control in which the object field is the replicaSubentry, and the modification list consists of one or two items: one to add the attribute attributeExclusionFilter and/or the other to add the attribute attributeInclusionFilter. If the server responds with a resultCode other than attributeOrValueExists or success, then an error has occurred. 4.6.3 Change Replica URI for one server for one area of replication Note: This section covers only the simple protocol operation to change the replica URI. Replication will carry this change to other servers. The client SHOULD invoke a ModifyRequest in which the object field is the replicationSubentry, and the modification list consists of a single item to change the value of the attribute replicaURI to the new value. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. 4.7 Add Replication Agreement Each server that acts as a supplier in replication sessions needs to have in its copy of the area of replication a replicaAgreementSubentry for each server that it replicates to. ReplicaAgreementSubentry objects are created as subordinates of the replicaSubentry representing the supplier server. These entries MUST have the following attributes: 1. objectclass, with values top, ldapSubentry and replicaAgreementSubentry-2, and 2. cn and MAY contain other attributes, as described in the Information Model [InfoMod]. The cn attribute value has no significance to replication. The cn attribute SHOULD have a value that is meaningful to the replication administrator. These objects MUST have the following attributes (defined as optional in the Information Model) for replication to occur: replicaDN Moats, et al Expires August 2002 [Page 7] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 If replicaDN is absent, no replication occurs under this agreement. WG Issue: We have asked Info Mod authors if there a reason to allow a replication agreement to be created without a replicaDN? The Information Model explicity allows this, but the effect is to cause the agreement to be ignored. We think the attribute should be a MUST, and further, that it should not be modifiable. A client AddRequest creates the replicaAgreementSubentry. The entry field of the AddRequest is the DN of the agreement (formed by using the cn attribute as the RDN naming attribute in combination with the DN of the parent replicaSubentry). The attributes field of the AddRequest contains the required attributes for the agreement and any optional attributes that are to be defined at this time. Note: while replicationAgreementSubentries could be replicated, since the replicationCredentialsDN are contained in the replicationAgreementSubentry, there is a bootstrapping issue with replicating via anonymous replication. To avoid this, clients MAY create the replicationAgreementSubentries on all servers. If they do this, they should use the AddWithMetaData operation (Section 4.15.1) to ensure that all replicationAgreementSubentries have the same entryUUID. 4.8 Delete Replication Agreement To delete a replication agreement a LDAP client SHOULD invoke a DeleteRequest naming the replicaAgreementSubentry to be deleted. The termination of replication agreements should be done with caution as it can easily result in a partition of the directory servers if performed incorrectly. Once all replication agreements have been terminated between a server and others for a naming context, then that copy of the context on the server will be divergent, and any updates made there will not be propagated to any other server. 4.9 Modify Replication Agreement To modify a replication agreement, the client SHOULD invoke a ModifyRequest naming the replicaAgreementSubentry. The modification list MAY include any of the following attributes: 1. attributeExclusionFilter 2. description 3. replicaDN 4. replicationMechanismOID 5. replicationCredentialsDN 6. replicationScheduleDN No further administrative action is required for these changes to take affect. Changing the replicaDN attribute has the effect of ending the existing agreement with the replica named by the old replicaDN value (if a value was present). Similary, changing the replicationMechanismOID attribute to specify ietf-ldup-full-update has the effect of ending incremental replication relationship. In this respect, these changes are equivalent to deleting a replication agreement and have the same Moats, et al Expires August 2002 [Page 8] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 considerations (see section 4.8) The replicationStatus attribute cannot be modified. 4.10 Suspend Replication The client SHOULD invoke a ModifyRequest in which the object field is the DN of the target replicationSubentry, and the modification list consists of a single item to change the value of replicaOnline attribute to false. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. If replicaOnline is FALSE for a replicaSubentry that represents the server containing the instance of the replicaSubentry, the server MUST NOT initiate or accept any new incremental replication sessions. If replicaOnline is FALSE for a replicaSubentry that represents a replica other than the server containing the instance of the replicaSubentry, the server MUST NOT initiate or accept any new incremental replication sessions with that replica. 4.11 Resume Replication The client SHOULD invoke a ModifyRequest in which the object field is the DN of the target replicationSubentry, and the modification list consists of a single item to change the value of replicaOnline attribute to true. If the server responds with the resultCode attributeOrValueExists, then the value is already there. If the server responds with a resultCode other than attributeOrValueExists or success, then this is an error. If replicaOnline is TRUE for a replicaSubentry that represents the server containing the instance of the replicaSubentry, the server MAY initiate or accept new incremental replication sessions. If replicaOnline is TRUE for a replicaSubentry that represents a replica other than the server containing the instance of the replicaSubentry, the server MAY initiate or accept new incremental replication sessions with that replica. 4.12 Trigger an Immediate Replica Cycle An immediate replication cycle can be triggered using an LDAP extended operation - "Trigger Replication". This operation takes 4 or 5 arguments: 1. The distinguished name of the replicaSubentry for the target replica. If there is no instance of this entry on the server where the extended operation is executed, the operation is not performed and an error is returned. 2. The LDAP URL of the target server. (Note: Per [Req] M8, a single Replication Agreement may accommodate more than one pair of servers. Thus this argument is necessary.) 3. Type of replication session to be performed (full update or incremental update). 4. Flags indicating whether the replication session is online or offline, and if offline whether the server should create the offline file or read the offline file. See Section 5.1.1 for more details of offline replication. Moats, et al Expires August 2002 [Page 9] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 5. If the replication session is offline, the name of the file to be used. All other required information (connection information, authentication information, etc.) is obtained from the Replication Agreement. The server on which the operation is executed immediately initiates a replica cycle with the target server. Updates are transferred in both directions if allowed by the replication agreement. If either the target server or the server executing the extended operation has a currently-active replica cycle for the replication context specified by the extended operation, the extended operation will fail ([Arch] Section 10). Since replication is normally an asynchronous operation, the Trigger Replication extended operation completes and returns status when replication is started. It does not wait for completion of the replica cycle and the returned status indicates whether the cycle was started successfully, not whether it completed successfully. Further progress of the replica cycle can be checked using other mechanisms (e.g. Section 5.9). The detailed syntax of the operation and associated response are presented in Section 6.3. 4.13 Immediately Terminate a Replica Cycle Note: this section discusses just the operation for terminating a replica cycle. See section 5.18 for a discussion of suspending replication or changing the replication schedule. An in-progress replication cycle can be terminated immediately using an LDAP extended operation - "Terminate Replication". This operation takes 2 arguments: 1. The distinguished name of the replicaSubentry for the target replica. If there is no instance of this entry on the server where the extended operation is executed, the operation is not performed and an error is returned. 2. The LDAP URL of the target server. (Note: Per [Req] M8, a single Replication Agreement may accommodate more than one pair of servers. Thus this argument is necessary.) All other required information is obtained from the Replication Agreement. The server on which the operation is executed immediately terminates its current replica cycle with the target server. Termination will not interrupt transmission of a Replication Update [Arch], it will occur only between Replication Updates. The detailed syntax of the operation and associated response are presented in Section 6.3. Note: If data is queued awaiting replication between a pair of servers and if replication is set to trigger on updates, the replication system may automatically start a new replica cycle shortly after a cycle is terminated. To avoid this, the replication schedule should be adjusted Moats, et al Expires August 2002 [Page 10] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 to suspend replication before the Terminate Replication extended operation is issued. 4.14 Search with Meta-Data Many pieces of replication meta-data are used by LDUP. In some cases (entryUUID, createdEntryCSN) they are stored as operational attributes and can be read using the LDAP search operation. Other meta-data (deleted entries, CSNs related to changes of attribute values) are not visible via normal LDAP operations but must be obtainable by administrative users attempting to deal with replication problems (e.g. dealing with Lost+Found entries). "Search with Meta-Data" is an extended operation that is modeled on the LDAP search operation [RFC2251]. There is an additional parameter that indicates what additional data should be returned be the search. The following values are permitted: - deletedEntries - Any deleted entries in the scope of the search are returned. Deleted entries can be distinguished from non- deleted entries because the deleted entries will have a value in their deletedEntryCSN attribute. If the deletedEntries controlValue is given, the deletedEntryCSN attribute is automatically added to the AttributeDescriptionList of the search. - attributeChangeState - Each attribute value returned as part of the search will be returned as a triple consisting of the attribute value, the deleted flag associated with the value, and the modificationCSN associated with the value. The formal specification of the Search with Meta-Data extended operation is given in Section 6.3. Note: Search with Meta-Data is designed as an extended operation rather than a control because the format of the returned data (sets of triples) is different from a normal LDAP search operation. Other than this, Search with Meta-Data operates the same as search. 4.15 Changing Replication Meta-Data When fixing a replication problem, administrators need a way to modify meta-data values that are normally treated as operational attributes (createdEntryCSN, entryUUID) or as completely hidden data (deletedEntryCSN, deleted flag, modificationCSN). This set of extended operations mirrors the normal LDAP operations that allow modification, but they allow modification of the associated meta- data as well. 4.15.1 Add with Meta-Data The Add with Meta-Data extended operation is modeled on the LDAP Add operation [RFC2251]. The differences from the standard LDAP Add operation are: - Each value is specified as a triple consisting of the value, the deleted flag to be associated with that value, and the modificationCSN to be associated with that value. - A value may be supplied for the createdEntryCSN attribute. Moats, et al Expires August 2002 [Page 11] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 - A value may be supplied for the entryUUID attribute. - If the Add with Meta-Data extended operation is executed on a readonly replica it will be executed locally rather than returning a referral to an updateable replica. The formal specification of Add with Meta-Data is in Section 6.3. 4.15.2 Delete with Meta-Data The Delete with Meta-Data extended operation is modeled on the LDAP Delete operation [RFC2251]. The differences from the standard LDAP Delete operation are: - A deletedEntryCSN may be supplied with the Delete with Meta-Data extended operation. In this case the delete operation is performed as in [RFC2251], except that the value of the deletedEntryCSN is taken from the controlValue. - It may be flagged as a noRecordDelete. In this case the targeted entry is deleted with no meta-data left behind (no deletedEntry or "tombstone"). - If the Delete with Meta-Data extended operation is executed on a readonly replica it will be executed locally rather than returning a referral to an updateable replica. The formal specification of the Delete with Meta-Data extended operation is given in Section 6.3. 4.15.3 Modify with Meta-Data The Modify with Meta-Data extended operation is modeled on the LDAP Modify operation [RFC2251]. The differences from the standard LDAP Modify operation are: - Each value is specified as a triple consisting of the value, the deleted flag to be associated with that value, and the modificationCSN to be associated with that value. - The createdEntryCSN attribute may be modified. - The entryUUID attribute may be modified. - If the Modify with Meta-Data extended operation is executed on a readonly replica it will be executed locally rather than returning a referral to an updateable replica. The formal specification of Modify with Meta-Data is in Section 6.3. 4.16 Write-Unwriteable Control There are a number of attributes defined in [InfoMod] which are marked "NO-USER-MODIFICATION". When fixing replication problems, there may be times when these values need to be changed. In addition, when administering readonly replicas it may be necessary for administrators to modify values on readonly replicas. The Write-Unwriteable control handles these cases. The control can be attached to an LDAP modify operation. If the control is present, it allows the modify operation to change values that are marked "NO-USER-MODIFICATION". Also, if the control is present, modify operations can be executed on readonly replicas. In this case the readonly replica will not return a referral to an Moats, et al Expires August 2002 [Page 12] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 updateable replica and the operation will be performed on the readonly replica. The formal specification of the control is given in Section 6.5. The current list of NO-USER-MODIFICATION attributes in [InfoMod] is: attributeExclusionFilter (Section 8.2.4) attributeInclusionFilter (Section 8.2.5) replicationStatus (Section 8.2.7) replicaType (Section 8.2.8) updateVector (Section 8.2.9) secondsToWaitDefault (Section 8.2.18) secondsToWait1 (Section 8.2.19) secondsToWait2 (Section 8.2.21) 5 Common Tasks There are many tasks that administrators need to perform in a replicated environment. This section describes many typical tasks and describes how they are performed in terms of the atoms defined above. 5.1 Add a new replica to an existing replica group Assume there is an existing replica group for a given area of replication. To add one new server (which does not already hold a copy of the area) to the replica group, perform the following steps: 1. Copy the base entry of the area of replication from one of the current servers to the new server (Section4.3). 2. On one of the existing servers in the replica group, create the replicaSubentry for the new server with the replicaOnline attribute set to "false" (Section 4.4). Replication will copy this to all the existing replicas (trigger immediate replication per Section 4.12 if necessary). Since replicaOnline does not replicate, it needs to be set "false" on all existing servers. 3. On the new server, create a replicaSubentry for one of the other servers in the replica group with the replicaOnline attribute set to "false". The UUID of this replicaSubentry MUST be identical to the UUID it has on the existing replicas, so Add with Meta- Data (Section 4.15.1) should be used to create the entry. 4. If the authentication mechanism used for replication requires credentials, make appropriate entries on all existing servers for the new server and make appropriate entries for all the existing servers on the new server. If any of the credential data is in the current area of replication, use Add with Meta-Data on the new server and make the UUIDs the same as those on the existing servers. 5. Create the replication agreement(s) on one of the existing servers and let it replicate to the other existing servers (Section 4.9). 6. Set the replicaOnline attribute to true for the new server on both the source and target servers (Section 4.11). 7. On the source server, trigger an immediate "full update" replica cycle (Section 4.12). The data replicated will include the replicaSubentries and replication agreements for all other servers in the replica group since they are in the area of replication. Moats, et al Expires August 2002 [Page 13] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 8. On the new server, set the replicaOnline attributes in the replicaSubentries for all the other servers to "true". 9. On the servers in the replica group other than the source server, set the replicaOnline attribute in the replicaSubentry for the target server to "true". 5.1.1 Large area of replication support In some cases, an area of replication is so large or available bandwidth so small that out-of-band mechanisms (e.g. mailing a tape) need to be used to transport the initial copy from the source to the target. The target then needs to be updated with changes made to the source since the copy was made. While LDIF is typically used to transport bulk LDAP data, it is not suitable here because it does not transport replication meta-data (CSNs, GUIDs, etc.). To ensure that all needed data is available; bulk replication data is stored as a stream of protocol elements from [Proto] in network byte order. There is an LDAP extended operation that will either cause a server to generate or read a stream of protocol elements (see Section 4.12). Use of the extended operation to generate or a read a file is OPTIONAL, but if the file is generated it MUST be a stream of protocol elements. The following restrictions are imposed on the data stream: - The BIND operation is unauthenticated. The extended operation that causes the destination server to read protocol elements from a local file should be restricted to privileged users only (See Section 7); this provides authentication for the operation. - The "supplier initiated" protocol flow is used. - A "full update" replication session is assumed. - Since input is coming from a file, there are no responses. The stream of protocol elements should assume that all response codes are "REPL_SUCCESS". - Since this is a "full update" session, [Proto] specifies that "the consumer's update vector should be assumed to be set to times 'earlier than' the oldest times known to the supplier server." Thus the protocol stream can be generated without receiving a createGroupingResponse extended operation from the consumer. - The value of the groupCookie in the endGroupingRequest extended operation is ignored. Once the file has been loaded on the destination server, the destination server should initiate a replication session with the source server (Section 4.14). This will pick up changes that have occurred since the original file was created. In summary, to add a new server to an existing replica group for a large replica, follow these steps (steps 1-7 are the same as steps 1-7 of Section 5.1): 1. Copy the base entry of the area of replication from one of the current servers to the new server (Section4.3). 2. On one of the existing servers in the replica group, create the replicaSubentry for the new server with the replicaOnline attribute set to "false" (Section 4.4). Replication will copy this to all the existing replicas. Since replicaOnline does not replicate, it needs to be set "false" on all existing servers. Moats, et al Expires August 2002 [Page 14] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 (Trigger immediate replication per Section 4.12 if necessary.) 3. On the new server, create a replicaSubentry for one of the other servers in the replica group with the replicaOnline attribute set to "false". The UUID of this replicaSubentry MUST be identical to the UUID it has on the existing replicas, so Add with Meta- Data (Section 4.15.1) should be used to create the entry. 4. If the authentication mechanism used for replication requires credentials, make appropriate entries on all existing servers for the new server and make appropriate entries for all the existing servers on the new server. If any of the credential data is in the current area of replication, use Add with Meta-Data on the new server and make the UUIDs the same as those on the existing servers. 5. Create the replication agreement(s) on one of the existing servers and let it replicate to the other existing servers (Section 4.9). 6. Set the replicaOnline attribute to "true" for the new server on both the source and target servers (Section 4.11). 7. Generate an update file on the source server (Section 4.12) 8. Transport the file to the destination site by any appropriate means 9. Load the file on the destination server 10. Import the file into LDAP (Section 4.12) 11. Set the replicaOnline attribute to true for the new server 12. Trigger a replica session between the source and destination machine to pick up changes since the file was generated (Section 4.12) 5.2 Verify replication information is present between two servers This section describes steps that verify the proper replication information is present for replication to occur between two replicas. There are two parts to this process: 1. Verify that the necessary objects have been created on both replicas. These objects include replicaSubentry objects representing the replicas, replication agreements describing consumer-supplier relationships between the replicas, and the credential and schedule objects named in the agreements. 2. Verify that it is valid to replicate between the replicas. For example, a fractional replica cannot act as a supplier to a full replica. 5.2.1 Verify that replication objects exist This section describes how to verify that the necessary replication objects exist. Within this section the term replica refers to one of the two replicas for which information is being verified. It is assumed that an administrator has identified the replicas (both the IP address/host name and the replicaId), the area of replication, and which of the replicas are expected to act as suppliers. One or both of the replicas must be a supplier to the other replica. 1. The client SHOULD invoke an object scope search specifying the DN of the root entry of the area of replication. This entry MUST exist on both servers, and the objectclass attribute values MUST include the value replicationContext. 2. On the replicas which the administrator has indicated is a supplier, the client SHOULD invoke a baseObject scope search of Moats, et al Expires August 2002 [Page 15] INTERNET DRAFT Mandatory LDAP Replica Management February 2002 the root DSE requesting the replicationSubentries attribute. The value for this attribute MUST name exactly one replicaSubentry object that is a child of the root entry of the area of replication. The distinguished name of the entry MUST be of the form: cn=, 3. On each supplier replica, the client SHOULD invoke a baseObject scope search specifying the DN of replicaSubentry that was identified in the replicaSubentries attribute of the root DSE in the previous step. This object MUST exist for replication to occur, and MUST include the value replicaSubentry in the list of objectclass values. The client SHOULD invoke an object scope search for the other server. The base DN for this search is of the form: cn=, where is the replicaId of the other replica. This object MUST exist, and MUST include the value replicaSubentry in the list objectclass values. 4. On each supplier replica, the client SHOULD invoke a singleLevel search, specifying the DN of replicaSubentry for that replica as the baseObject, and a search filter like: (&(objectclass=replicationAgreementSubentry-2) (replicaDN=)) where ; Tue, 19 Feb 2002 05:49:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1JAd8w12000 for ietf-ldup-bks; Tue, 19 Feb 2002 02:39:08 -0800 (PST) Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1JAd3311995 for ; Tue, 19 Feb 2002 02:39:03 -0800 (PST) Received: from CHRIS-H.opengroup.org (dhcp192-153-166-52.rdg.opengroup.org [192.153.166.52]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g1JAc7g04893; Tue, 19 Feb 2002 10:38:08 GMT Message-Id: <5.1.0.14.1.20020219103818.00ac6550@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 10:40:22 +0000 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org, ietf-ldapbis@OpenLDAP.org, ldap@umich.edu From: Chris Harding Subject: Plugfest - Last Chance to Register Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4233607==_.ALT" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_4233607==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi - Registrations close tomorrow! (At midnight PST on, Wednesday February 20th). >Test your applications for Works with LDAP 2000 compliance! > >The DIF's 2nd Plugfest offers you the opportunity to test your >applications for interoperability with servers from leading vendors such >as Oracle, Novell, IBM and more, all at the time and the same location. At >our last Plugfest, 8 leading server vendors provided hardware and HP, >PeopleSoft and SAP were among the 20 applications that tested and received >the Open Group's Works with LDAP certification. > >Expand the market for your applications by providing prospects with >guaranteed interoperability in a host of infrastructure environments. > >This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The >cost to participate is $495 dollars, which is waived when you choose to >brand your application as Works with LDAP. > >More detailed information about this Plugfest and Works with LDAP >certification is available at the DIF website at >http://www.opengroup.org/dif/. Register on the web, or contact me. > >I look forward to seeing you, Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== The Open Group Conference - "Managing The Mobile Workforce" Paris, France, 8-12 April 2002 http://www.opengroup.org/paris2002 ======================================================================== --=====================_4233607==_.ALT Content-Type: text/html; charset="us-ascii"  Hi -

Registrations close tomorrow!  (At midnight PST on, Wednesday February 20th).

Test your applications for Works with LDAP 2000 compliance!

The DIF's 2nd Plugfest offers you the opportunity to test your applications for interoperability with servers from leading vendors such as Oracle, Novell, IBM and more, all at the time and the same location. At our last Plugfest, 8 leading server vendors provided hardware and HP, PeopleSoft and SAP were among the 20 applications that tested and received the Open Group's Works with LDAP certification.

Expand the market for your applications by providing prospects with guaranteed interoperability in a host of infrastructure environments.
 
This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The cost to participate is $495 dollars, which is waived when you choose to brand your application as Works with LDAP.

More detailed information about this Plugfest and Works with LDAP certification is available at the DIF website at http://www.opengroup.org/dif/. Register on the web, or contact me.

I look forward to seeing you,



Regards,

Chris
+++++

========================================================================
           Dr. Christopher J. Harding
  T H E    Executive Director for the Directory Interoperability Forum
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:c.harding@opengroup.org Phone:  +44 118 950 8311 x2262
           WWW: http://www.opengroup.org Mobile: +44 774 063 1520
========================================================================
The Open Group Conference - "Managing The Mobile Workforce"
Paris, France, 8-12 April 2002
http://www.opengroup.org/paris2002
========================================================================
--=====================_4233607==_.ALT-- From owner-ietf-ldup@mail.imc.org Tue Feb 19 07:18:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15753 for ; Tue, 19 Feb 2002 07:18:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1JCA3l17625 for ietf-ldup-bks; Tue, 19 Feb 2002 04:10:03 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1JCA0317613 for ; Tue, 19 Feb 2002 04:10:00 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15244; Tue, 19 Feb 2002 07:09:59 -0500 (EST) Message-Id: <200202191209.HAA15244@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-mrm-01.txt Date: Tue, 19 Feb 2002 07:09:59 -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 : Mandatory LDAP Replica Management Author(s) : R. Moats, R. Huber, J. McMeeking Filename : draft-ietf-ldup-mrm-01.txt Pages : 15 Date : 18-Feb-02 The goal of standards for LDAP replication is to allow interoperable replication among products from many different vendors. Defining the mechanism to move data among replicas is a necessary part of this work, but management of the replicated environment must also be standardized for replication to be truly interoperable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-01.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-mrm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-mrm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020218134304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-mrm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-mrm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020218134304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Feb 19 08:23:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17504 for ; Tue, 19 Feb 2002 08:23:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1JD9Zf21808 for ietf-ldup-bks; Tue, 19 Feb 2002 05:09:35 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1JD9Y321804 for ; Tue, 19 Feb 2002 05:09:34 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Tue, 19 Feb 2002 08:08:05 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 19 Feb 2002 08:07:54 -0700 From: "Ed Reed" To: Subject: ldup scheduled Wed 9-11:30am, ldapbis Thu 9-11:30 [eot] Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From owner-ietf-ldup@mail.imc.org Mon Feb 25 22:17:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07793 for ; Mon, 25 Feb 2002 22:17:22 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1Q33es17133 for ietf-ldup-bks; Mon, 25 Feb 2002 19:03:40 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1Q33c317129 for ; Mon, 25 Feb 2002 19:03:38 -0800 (PST) Received: (qmail 27118 invoked from network); 26 Feb 2002 03:04:22 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 26 Feb 2002 03:04:22 -0000 Reply-To: From: "Steven Legg" To: , Subject: Basic Access Control for LDAP Date: Tue, 26 Feb 2002 14:02:26 +1100 Message-ID: <006001c1be72$059fc330$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, I've submitted two I-Ds that together describe a profile of the X.500 Basic Access Control and Simplified Access Control schemes for use in LDAP. Both drafts are now available from the on-line Internet-Drafts directories. Title : Access Control Administration in LDAP Author(s) : S. Legg Filename : draft-legg-ldap-acm-admin-00.txt Pages : 11 Date : 22-Feb-02 This document adapts the X.500 directory administrative model for use by the Lightweight Directory Access Protocol. The administrative model partitions the Directory Information Tree for various aspects of directory data administration, e.g. subschema, access control and collective attributes. The generic framework that applies to every aspect of administration is described, along with the particular definitions that support Access Control administration. This document does not define a particular access control scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-admin-00.txt Title : Basic and Simplified Access Control in LDAP Author(s) : S. Legg Filename : draft-legg-ldap-acm-bac-00.txt Pages : 41 Date : 22-Feb-02 An access control scheme describes the means by which access to directory information and potentially to access rights themselves may be controlled. This document adapts the X.500 directory Basic Access Control and Simplied Access Control schemes for use by the Lightweight Directory Access Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-bac-00.txt Cheers, Steven From owner-ietf-ldup@mail.imc.org Tue Feb 26 08:16:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27606 for ; Tue, 26 Feb 2002 08:16:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QD7OM04305 for ietf-ldup-bks; Tue, 26 Feb 2002 05:07:24 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QD7N304296 for ; Tue, 26 Feb 2002 05:07:23 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Tue, 26 Feb 2002 08:04:58 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 26 Feb 2002 08:04:46 -0700 From: "Ed Reed" To: , Cc: Subject: RE: Replica Management - subtreespecification attribute Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1QD7N304298 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I can't tell if concensus was reached on this or not, so I'll bring it up again... The purpose of placing the subtree specification, along with other scoping information, onto the replicaSubentry was precisely to create a single entry that would define the replication context. The purpose of allowing additional scoping information to refine what is to be passed along certain replicationAgreements between particular replicas was to control the flow of changes across certain links in the replica topology. By refinement, I mean further contraint. ReplicaAgreements inherit, by subordination in the namespace, the knowledge about what entries and attributes are contained in the replica they're subordinate to, and to which they refer (by the very DN syntax method you suggest). If my proposed model of name subordination is abandoned for replicaAgreements, then of course, there will need to be a DN reference to the second endpoint of the replicaAgreement association (falling into DEN-eese, here). Or to all of them, if it's to be multivalued. Tim - have we decided to move away from hierarchical subentries, so as to more completely and "purely" embrace the X.501 subentry syntax? If so, you'll wind up with a "bag" of replicaSubentries, together with a "bag" of replicationAgreements, all necessarily shared/known by all replicas, with some arbitrary graph where replicaSubentries are nodes of the graph and replicationAgreements are the edges. It will then be encombant on administrators (and their tools) to ensure that the graph remains connected, that there are no black holes (replicaSubentries which are updateable but have no outbound path of propagating changes to others), etc. In otherwords, that there remains a "correct" graph, for some definition of "correct". I must say I dislike designs that place the responsibility for insuring "correct" deployment on the administrators. I much prefer designs which create systems that are correct to begin with, and that can then be broken, if necessary, with enough mule-headed persistance of those administrators. Anyway. Rick - I think your desire for an entry, somewhere, that describes the replication context (scope) that will be shared by all the replicaSubentries (and possibly refined by them) is a good one. In the absense of a "primary" replica (my preferred method of solving this problem), I suggest that a subentry be defined that explicitly is used to designate the anchor point for the ldup administrative area that coincides with the replication context. For clarity, here, I reproduce from memory what I mean by those words... A replication context is a partion of the DIT for which there are one or more replicas. Each replica is represented by a replicationSubentry immediately subordinate to the base entry of the replication context. Replicas of the replication context may be full or partial. If they are administratively constrained to hold less than the full replication context (ie, all the entries and all their attributes in the partion of the DIT represented by the replication context), the refinements (constraints) for each replica are represented by filters on the respective replicaSubentry for that replica. Note that I'm explicitly using terminology here to preclude the notion that a replica holds MORE than ALL the entries and attributes of the DIT, because that seems nonsensical. The data in the DIT is the data in the DIT. (Aside - if the replica context EXPLICITLY lists the entries or attributes, by including filters in its very definition, then it is effectively PROHIBITING subordinate replicas from holding information not permitted in those filters. On the other hand, if it's not prohibited, as would be the case when there are no filters on the replica context definition, then subordinate replicas MIGHT define schema elements locally that THEY can hold, but which cannot be held by other replicas unless the changes to the schema can be propagated via LDUP - which may or may not be possible, depending on the replication agreements and constraints defined on those other replicas). As aluded to, above, replicationAgreements, which document the dataflow between replicas, may themselves have constraints as to the entries and/or attributes which may be passed across them. Again, though, those constraints, if present, cannot by definition exceed the set of entries and attributes permitted by replica context definition (however it is represented). So, again, if the replica context definition is permissive, subordinate replicas and their replicationAgreements can create local extensions of the schema they share among themselves. But if explicitly defined through constraints, the replica context schema definition cannot be expanded upon in ways to permit in a replica or replicationAgreement what is prohibited by the replica context definition. Make sense? Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Steven Legg" 01/28/02 11:45PM >>> Rick, Richard V Huber wrote: > We noted in a previous email that, to allow overlapping areas of > replication, we feel that an area of replication is defined by a > replicaSubentry. The replicaSubentry defines the boundary of the area > via the subtreespecification attribute. Note that a subtree specification identifies a collection of entries, but not a subset of the attributes within them. That is, it specifies the sparseness of a partial replica. Something else in addition to the subtree specification is required to specify the fractionalness of a partial replica, i.e. the attributeExclusionFilter and attributeInclusionFilter attributes. Regarding terminology, you appear to be using "area of replication" to mean some part, possibly but not necessarily all, of the information in a replication context. Thus a single replication context can have more than one area of replication within its scope. This is what I assume it means, however areas of replication (a.k.a replication areas) are not defined in the architecture and model drafts and tend to be used as synonyms for "replication context". > Because a subtreespecification may need to be shared across a > number of > subentries (e.g. all the replicaSubentries that refer to a common area > of replication), we would like to have a single subtreespecification > that can be referenced from multiple subentries. Accordingly, we > would like to change the subentry objectclass to use > subtreeSpecificationDN and allow the subtree specification to > be stored > as a separate entry which can be referenced as needed. This separate (sub?)entry would contain the attributeExclusionFilter and attributeInclusionFilter attributes as well. An alternative to a subtreeSpecificationDN attribute would be to place the replica subentries subordinate to the (sub)entry describing their area of replication. Either way, I would support making such a change to the information model. Regards, Steven > > This may be useful in other cases where a single subtreespecification > needs to be used consistently in several places. >nis effectively PROHIBITING subordinate r > Rick Huber > John McMeeking > Ryan Moats > From owner-ietf-ldup@mail.imc.org Wed Feb 27 12:09:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03611 for ; Wed, 27 Feb 2002 12:09:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RGtaO28453 for ietf-ldup-bks; Wed, 27 Feb 2002 08:55:36 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RGtZ328447 for ; Wed, 27 Feb 2002 08:55:35 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Wed, 27 Feb 2002 11:53:01 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 27 Feb 2002 11:52:50 -0700 From: "Ed Reed" To: , , Subject: Re: Basic Access Control for LDAP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1RGtZ328448 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit One question from reading the drafts (for now) - What constitutes a "user" for the purpose of ACI UserClasses value allUsers? Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Steven Legg" 02/25/02 10:02PM >>> Folks, I've submitted two I-Ds that together describe a profile of the X.500 Basic Access Control and Simplified Access Control schemes for use in LDAP. Both drafts are now available from the on-line Internet-Drafts directories. Title : Access Control Administration in LDAP Author(s) : S. Legg Filename : draft-legg-ldap-acm-admin-00.txt Pages : 11 Date : 22-Feb-02 This document adapts the X.500 directory administrative model for use by the Lightweight Directory Access Protocol. The administrative model partitions the Directory Information Tree for various aspects of directory data administration, e.g. subschema, access control and collective attributes. The generic framework that applies to every aspect of administration is described, along with the particular definitions that support Access Control administration. This document does not define a particular access control scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-admin-00.txt Title : Basic and Simplified Access Control in LDAP Author(s) : S. Legg Filename : draft-legg-ldap-acm-bac-00.txt Pages : 41 Date : 22-Feb-02 An access control scheme describes the means by which access to directory information and potentially to access rights themselves may be controlled. This document adapts the X.500 directory Basic Access Control and Simplied Access Control schemes for use by the Lightweight Directory Access Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-bac-00.txt Cheers, Steven From owner-ietf-ldup@mail.imc.org Wed Feb 27 12:26:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04587 for ; Wed, 27 Feb 2002 12:26:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RHF8x29589 for ietf-ldup-bks; Wed, 27 Feb 2002 09:15:08 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RHF6329583 for ; Wed, 27 Feb 2002 09:15:06 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.us.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA85560 for ; Wed, 27 Feb 2002 12:11:34 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1RHEhK54992 for ; Wed, 27 Feb 2002 12:14:43 -0500 Subject: RE: Replica Management - subtreespecification attribute To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Wed, 27 Feb 2002 12:06:10 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V5010_0212_dev00 |February 14, 2002) at 02/27/2002 12:14:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, Sorry for being silent for awhile on this topic - too many things to do. I've put some comments below with ... I have NOT updated the infomod document yet, we'll see how this line of discussion pans out before I do that. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Ed Reed" , M> cc: Sent by: Subject: RE: Replica Management - subtreespecification attribute owner-ietf-ldup@m ail.imc.org 02/26/2002 10:04 AM I can't tell if concensus was reached on this or not, so I'll bring it up again... The purpose of placing the subtree specification, along with other scoping information, onto the replicaSubentry was precisely to create a single entry that would define the replication context. I agree with this. The purpose of allowing additional scoping information to refine what is to be passed along certain replicationAgreements between particular replicas was to control the flow of changes across certain links in the replica topology. By refinement, I mean further contraint. ReplicaAgreements inherit, by subordination in the namespace, the knowledge about what entries and attributes are contained in the replica they're subordinate to, and to which they refer (by the very DN syntax method you suggest). I don't agree with this "subtle change in usage" of the subtreespecification setting in the replicationAgreement entries. Why? I guess I just see this as too confusing. I'm sort of "on the fence" on this one, so I could be convinced otherwise I guess. What's the consensus? If my proposed model of name subordination is abandoned for replicaAgreements, then of course, there will need to be a DN reference to the second endpoint of the replicaAgreement association (falling into DEN-eese, here). Or to all of them, if it's to be multivalued. Tim - have we decided to move away from hierarchical subentries, so as to more completely and "purely" embrace the X.501 subentry syntax? I have NOT moved away from name subordination - I still think it is a good idea to make use of the hierachy of entries to organize these. If so, you'll wind up with a "bag" of replicaSubentries, together with a "bag" of replicationAgreements, all necessarily shared/known by all replicas, with some arbitrary graph where replicaSubentries are nodes of the graph and replicationAgreements are the edges. It will then be encombant on administrators (and their tools) to ensure that the graph remains connected, that there are no black holes (replicaSubentries which are updateable but have no outbound path of propagating changes to others), etc. In otherwords, that there remains a "correct" graph, for some definition of "correct". I must say I dislike designs that place the responsibility for insuring "correct" deployment on the administrators. I much prefer designs which create systems that are correct to begin with, and that can then be broken, if necessary, with enough mule-headed persistance of those administrators. Anyway. Rick - I think your desire for an entry, somewhere, that describes the replication context (scope) that will be shared by all the replicaSubentries (and possibly refined by them) is a good one. In the absense of a "primary" replica (my preferred method of solving this problem), I suggest that a subentry be defined that explicitly is used to designate the anchor point for the ldup administrative area that coincides with the replication context. I've been hoping, perhaps naively, that the update reconciliation rules and update replication protocol itself would be used to transfer the subentry information between servers as well, allowing the "administration point" to contact the server of its choice (within bounds of course) in setting things up. I've been reluctant to require the designation of any one server in the replication topology as the "master master" or "primary master", in hopes that the LDUP models would allow administration of topology to be done in a distributed manner as well. For clarity, here, I reproduce from memory what I mean by those words... A replication context is a partion of the DIT for which there are one or more replicas. Each replica is represented by a replicationSubentry immediately subordinate to the base entry of the replication context. Replicas of the replication context may be full or partial. If they are administratively constrained to hold less than the full replication context (ie, all the entries and all their attributes in the partion of the DIT represented by the replication context), the refinements (constraints) for each replica are represented by filters on the respective replicaSubentry for that replica. Note that I'm explicitly using terminology here to preclude the notion that a replica holds MORE than ALL the entries and attributes of the DIT, because that seems nonsensical. The data in the DIT is the data in the DIT. (Aside - if the replica context EXPLICITLY lists the entries or attributes, by including filters in its very definition, then it is effectively PROHIBITING subordinate replicas from holding information not permitted in those filters. On the other hand, if it's not prohibited, as would be the case when there are no filters on the replica context definition, then subordinate replicas MIGHT define schema elements locally that THEY can hold, but which cannot be held by other replicas unless the changes to the schema can be propagated via LDUP - which may or may not be possible, depending on the replication agreements and constraints defined on those other replicas). In light of what I said above, perhaps replication and/or subentry information must be replicated all the time, without regard to the scoping and filtering done for "other entries". Further, administration of topology MUST be performed on SOME server that will allow this information to "eventually appear" on ALL servers in the topology (e.g. you can't administer replication agreements on a server that is not configured to replicate TO anyone else) As aluded to, above, replicationAgreements, which document the dataflow between replicas, may themselves have constraints as to the entries and/or attributes which may be passed across them. Again, though, those constraints, if present, cannot by definition exceed the set of entries and attributes permitted by replica context definition (however it is represented). So, again, if the replica context definition is permissive, subordinate replicas and their replicationAgreements can create local extensions of the schema they share among themselves. But if explicitly defined through constraints, the replica context schema definition cannot be expanded upon in ways to permit in a replica or replicationAgreement what is prohibited by the replica context definition. Make sense? Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Steven Legg" 01/28/02 11:45PM >>> Rick, Richard V Huber wrote: > We noted in a previous email that, to allow overlapping areas of > replication, we feel that an area of replication is defined by a > replicaSubentry. The replicaSubentry defines the boundary of the area > via the subtreespecification attribute. Note that a subtree specification identifies a collection of entries, but not a subset of the attributes within them. That is, it specifies the sparseness of a partial replica. Something else in addition to the subtree specification is required to specify the fractionalness of a partial replica, i.e. the attributeExclusionFilter and attributeInclusionFilter attributes. Regarding terminology, you appear to be using "area of replication" to mean some part, possibly but not necessarily all, of the information in a replication context. Thus a single replication context can have more than one area of replication within its scope. This is what I assume it means, however areas of replication (a.k.a replication areas) are not defined in the architecture and model drafts and tend to be used as synonyms for "replication context". > Because a subtreespecification may need to be shared across a > number of > subentries (e.g. all the replicaSubentries that refer to a common area > of replication), we would like to have a single subtreespecification > that can be referenced from multiple subentries. Accordingly, we > would like to change the subentry objectclass to use > subtreeSpecificationDN and allow the subtree specification to > be stored > as a separate entry which can be referenced as needed. This separate (sub?)entry would contain the attributeExclusionFilter and attributeInclusionFilter attributes as well. An alternative to a subtreeSpecificationDN attribute would be to place the replica subentries subordinate to the (sub)entry describing their area of replication. Either way, I would support making such a change to the information model. Regards, Steven > > This may be useful in other cases where a single subtreespecification > needs to be used consistently in several places. >nis effectively PROHIBITING subordinate r > Rick Huber > John McMeeking > Ryan Moats > From owner-ietf-ldup@mail.imc.org Wed Feb 27 17:25:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22287 for ; Wed, 27 Feb 2002 17:25:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RMCoV07940 for ietf-ldup-bks; Wed, 27 Feb 2002 14:12:50 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RMCli07935; Wed, 27 Feb 2002 14:12:47 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA259544; Wed, 27 Feb 2002 17:08:35 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1RMBkd149680; Wed, 27 Feb 2002 17:11:47 -0500 From: "John McMeeking" Subject: RE: Replica Management - subtreespecification attribute To: "Ed Reed" Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, rvh@qsun.mt.att.com, steven.legg@adacel.com.au X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 27 Feb 2002 16:11:50 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 02/27/2002 04:11:49 PM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B Content-type: multipart/alternative; Boundary="1__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B" --1__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B Content-type: text/plain; charset=US-ASCII My two bits worth: First, I have to confess that I am not sure that supporting overlapping areas of replication is worth the effort. But that may be just because I haven't had a need for it. Here's what I would do: An area of replication is defined by a "replicationAreaSubentry" placed immediately below the root of the area of replication. If the replicationAreaSubentry has a subtree specification, the subtree specification defines the bounds of the area of replication. In the absense of a subtree specification, the area of replication extends downwards through the DIT until reaching another area of replication. That much should be in keeping with x.500 administrative areas. The replicationContext auxiliary class would go away. A replicaSubentry describes a single server's role in a single area of replication. The area of replication that the subentry applies to is identified by a new single-valued "areaOfReplication" attribute. ReplicaSubentries can be located anywhere within the area of replication; there is no need to be just below the root entry. subtreeSpecifications on a replicaSubentry are not allowed. Do not allow refinements on agreements, unless someone can describe a realistic scenario where the consumer server claims to support certain attributes, but those attribute should not be replicated to it by certain servers. Otherwise, the rest of replicaSubentry and replication agreements can stand is is. From a replication protocol perspective, an area of replication would be identified by the DN of the replicationAreaSubentry. If a server holds overlapping areas of replication, any change which applies to multiple areas would be replicated under all areas of replication. The change should be idempotent (and hopefully fast compared to a new update) from perspective of the consumer, but it does chew up extra bandwidth. This is necessary to make update vectors work properly. And here's why -- my experience says I really need people in a room and a whiteboard to get through these discussions,but I'll try a note anyway: There is some behavior related to the use of update vectors that requires careful consideration when defining multiple areas of replication rooted at the same entry, or further refining replication at the subentry or replication agreement level. First, imbedded in the protocol is the notion that an update vector is associated with a replicated area. When starting a replication session, the supplier identifies the replicated area and the consumer responds with its update vector for that area. A consumer server ignores replication updates that have CSNs covered by its update vector. Right now, it is assumed that the replicated area is identified by the DN of an entry that is decorated with the replicationContext auxiliary class. That could be changed, but right now, it happens that the update vector is associated with a replicaSubentry, and each replica is represented by a single replicaSubentry immediately subordinate to the replicationContext. I think most people expect that each server corresponds to exactly one replica and replicaSubentry. If I have all this right, then it follws that each server has one update vector associated with each replicationContext entry. Second, purge processing makes use of the update vectors. A server can purge meta-data based on a purge vector that is the minimum of all the update vectors for a given replicated area. Currently, this would be the update vectors associated with each replicasubentry beneath a replicationContext. Consider the following scenarios... Scenario 1: I have three servers, S1, S2, and S3, all containing replicas of replicated area A. There are agreements between all of these servers, and the agreement S2 to S3 has a subtreespecification (or other refinement). A series of changes, C1 (CSN = T1-1) and C2 (CSN=T1-2), is made at S1, such that C1 is outside the subtreespecification attached to the S2 to S3 agreement. Finally, lets assume that scheduling of replication is such that S1 replicates to S2, then S2 replicates to S3, and then S1 replicates to S3. - S1 replicates to S2: S1 replicates both C1 and C2 to S2. S2 sets its update vector to reflecting that it has received changes through T1-2 originating at S1. - S2 replicates to S3: S2 replicates C2 to S3, but not C1 (due to subtreespecification on the agreement). S3 sets its update vector to . - S1 replicates to S3. S3 sends its update vector to S1. S1 notes that S3 has seen all changes through T1-2, and sends nothing. S3 does not receive change C1. Based on this, I believe that we cannot allow refinements on agreements. Scenario 2: I have three servers, S1, S2, and S3, all containing replicated area A. However, the subentry for S2 has a subtree specification that excludes some portion of the area. There are agreements between all these servers. A series of changes, C1 (CSN=T1-1 and C2 (CSN = T1-2) is made at S1 such that C1 is outside of the subtree specification for S2. Finally, lets assume that scheduling of replication is such that S1 replicates to S2, then S2 replicates to S3, and then S1 replicates to S3. - S1 replicates to S2. S1 does not replicate C1 to S2 (not within the S2's subtree specification), S1 does replicate C2. S2 sets its update vector to - S2 replicates to S3. S2 sends C2 to S3. S3 sets its update vector to . - S1 replicates to S3. S3 sends its update vector to S1. S1 notes that S3 has seen changes through T1-2 and sends nothing. S3 does not ever receive change C1. Based on this, I believe that S2 cannot be allowed to replicate to S3 -- Replica S2 cannot act as a supplier to replica S3 if S2 is a proper subset of S3. One alternative is that S2 accept changes outside its subtree specification and that it replicate them, but does not store them in its DIT. I don't imagine that flying well. Scenario 3: Take scenario two, but make a series of changes at S1 -- C1, C2 ... , such that only C1 falls within the subtree specification for S2. - S1 replicates to S2. S1 sends C1, but not C2...Cn. S2 sets its update vector to - S2 cannot replicate to S3 (S2 is a subset of S3). - S1 replicates to S3. S3 sends its update vector to S1, and S1 sends C1...Cn to S3. S3 sets its update vector to - S1 does purge processing. It notes that its copy of the update vector for S2 has T1-1. No changes after T1-1 are purged until a change is made at S1 that falls within the subtree specification for S2. This violates the requirement that meta-data cannot grow without bound. One alternative is that S2 accept all changes for purposes of setting the updatde vector properly, but that S2 does not store or replicate changes not within its subtree specification. Once again, I don't see this flying. This suggests that S1 cannot act as a supplier to S2 if the subtree specifications for S1 and S2 are not the same. That doesn't make sense: if S1 is a superset of S2, as is the case here, it ought to be able to act as a supplier, but the current architecture seems to prevent that. Where next? I think we need a few things to make overlapping areas of replication work [or we can disallow it]: - We need a way to define/identify each of the areas of replication. replicationContext objectclass doesn't cut it if two areas can have the same root. Subtree specification as part of a subentry (as opposed to a referenced specification) pretty much makes each subentry its own area of replication, which might simplify to "no replication". A separate object, as you suggest, seems to make the most sense. - We need a way to associate an update vector with each area of replication, where two areas of replication rooted at the same entry requires two update vectors. Update vectors are an attribute of replicaSubentries. I don't see anything in InfoMod which would prevent there being multiple subentries representing the same physical server, so one solution would be to create separate replica subentries for each area of replication that a server participates in. John McMeeking "Ed Reed" , COM> cc: Sent by: owner- Subject: RE: Replica Management - subtreespecification attribute ietf-ldup@mail. imc.org 02/26/2002 09:04 AM I can't tell if concensus was reached on this or not, so I'll bring it up again... The purpose of placing the subtree specification, along with other scoping information, onto the replicaSubentry was precisely to create a single entry that would define the replication context. The purpose of allowing additional scoping information to refine what is to be passed along certain replicationAgreements between particular replicas was to control the flow of changes across certain links in the replica topology. By refinement, I mean further contraint. ReplicaAgreements inherit, by subordination in the namespace, the knowledge about what entries and attributes are contained in the replica they're subordinate to, and to which they refer (by the very DN syntax method you suggest). If my proposed model of name subordination is abandoned for replicaAgreements, then of course, there will need to be a DN reference to the second endpoint of the replicaAgreement association (falling into DEN-eese, here). Or to all of them, if it's to be multivalued. Tim - have we decided to move away from hierarchical subentries, so as to more completely and "purely" embrace the X.501 subentry syntax? If so, you'll wind up with a "bag" of replicaSubentries, together with a "bag" of replicationAgreements, all necessarily shared/known by all replicas, with some arbitrary graph where replicaSubentries are nodes of the graph and replicationAgreements are the edges. It will then be encombant on administrators (and their tools) to ensure that the graph remains connected, that there are no black holes (replicaSubentries which are updateable but have no outbound path of propagating changes to others), etc. In otherwords, that there remains a "correct" graph, for some definition of "correct". I must say I dislike designs that place the responsibility for insuring "correct" deployment on the administrators. I much prefer designs which create systems that are correct to begin with, and that can then be broken, if necessary, with enough mule-headed persistance of those administrators. Anyway. Rick - I think your desire for an entry, somewhere, that describes the replication context (scope) that will be shared by all the replicaSubentries (and possibly refined by them) is a good one. In the absense of a "primary" replica (my preferred method of solving this problem), I suggest that a subentry be defined that explicitly is used to designate the anchor point for the ldup administrative area that coincides with the replication context. For clarity, here, I reproduce from memory what I mean by those words... A replication context is a partion of the DIT for which there are one or more replicas. Each replica is represented by a replicationSubentry immediately subordinate to the base entry of the replication context. Replicas of the replication context may be full or partial. If they are administratively constrained to hold less than the full replication context (ie, all the entries and all their attributes in the partion of the DIT represented by the replication context), the refinements (constraints) for each replica are represented by filters on the respective replicaSubentry for that replica. Note that I'm explicitly using terminology here to preclude the notion that a replica holds MORE than ALL the entries and attributes of the DIT, because that seems nonsensical. The data in the DIT is the data in the DIT. (Aside - if the replica context EXPLICITLY lists the entries or attributes, by including filters in its very definition, then it is effectively PROHIBITING subordinate replicas from holding information not permitted in those filters. On the other hand, if it's not prohibited, as would be the case when there are no filters on the replica context definition, then subordinate replicas MIGHT define schema elements locally that THEY can hold, but which cannot be held by other replicas unless the changes to the schema can be propagated via LDUP - which may or may not be possible, depending on the replication agreements and constraints defined on those other replicas). As aluded to, above, replicationAgreements, which document the dataflow between replicas, may themselves have constraints as to the entries and/or attributes which may be passed across them. Again, though, those constraints, if present, cannot by definition exceed the set of entries and attributes permitted by replica context definition (however it is represented). So, again, if the replica context definition is permissive, subordinate replicas and their replicationAgreements can create local extensions of the schema they share among themselves. But if explicitly defined through constraints, the replica context schema definition cannot be expanded upon in ways to permit in a replica or replicationAgreement what is prohibited by the replica context definition. Make sense? Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Steven Legg" 01/28/02 11:45PM >>> Rick, Richard V Huber wrote: > We noted in a previous email that, to allow overlapping areas of > replication, we feel that an area of replication is defined by a > replicaSubentry. The replicaSubentry defines the boundary of the area > via the subtreespecification attribute. Note that a subtree specification identifies a collection of entries, but not a subset of the attributes within them. That is, it specifies the sparseness of a partial replica. Something else in addition to the subtree specification is required to specify the fractionalness of a partial replica, i.e. the attributeExclusionFilter and attributeInclusionFilter attributes. Regarding terminology, you appear to be using "area of replication" to mean some part, possibly but not necessarily all, of the information in a replication context. Thus a single replication context can have more than one area of replication within its scope. This is what I assume it means, however areas of replication (a.k.a replication areas) are not defined in the architecture and model drafts and tend to be used as synonyms for "replication context". > Because a subtreespecification may need to be shared across a > number of > subentries (e.g. all the replicaSubentries that refer to a common area > of replication), we would like to have a single subtreespecification > that can be referenced from multiple subentries. Accordingly, we > would like to change the subentry objectclass to use > subtreeSpecificationDN and allow the subtree specification to > be stored > as a separate entry which can be referenced as needed. This separate (sub?)entry would contain the attributeExclusionFilter and attributeInclusionFilter attributes as well. An alternative to a subtreeSpecificationDN attribute would be to place the replica subentries subordinate to the (sub)entry describing their area of replication. Either way, I would support making such a change to the information model. Regards, Steven > > This may be useful in other cases where a single subtreespecification > needs to be used consistently in several places. >nis effectively PROHIBITING subordinate r > Rick Huber > John McMeeking > Ryan Moats > --1__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B Content-type: text/html; charset=US-ASCII Content-Disposition: inline

My two bits worth:

First, I have to confess that I am not sure that supporting overlapping areas of replication is worth the effort. But that may be just because I haven't had a need for it.

Here's what I would do:

An area of replication is defined by a "replicationAreaSubentry" placed immediately below the root of the area of replication. If the replicationAreaSubentry has a subtree specification, the subtree specification defines the bounds of the area of replication. In the absense of a subtree specification, the area of replication extends downwards through the DIT until reaching another area of replication. That much should be in keeping with x.500 administrative areas. The replicationContext auxiliary class would go away.

A replicaSubentry describes a single server's role in a single area of replication. The area of replication that the subentry applies to is identified by a new single-valued "areaOfReplication" attribute. ReplicaSubentries can be located anywhere within the area of replication; there is no need to be just below the root entry. subtreeSpecifications on a replicaSubentry are not allowed.

Do not allow refinements on agreements, unless someone can describe a realistic scenario where the consumer server claims to support certain attributes, but those attribute should not be replicated to it by certain servers.

Otherwise, the rest of replicaSubentry and replication agreements can stand is is.

From a replication protocol perspective, an area of replication would be identified by the DN of the replicationAreaSubentry. If a server holds overlapping areas of replication, any change which applies to multiple areas would be replicated under all areas of replication. The change should be idempotent (and hopefully fast compared to a new update) from perspective of the consumer, but it does chew up extra bandwidth. This is necessary to make update vectors work properly.


And here's why -- my experience says I really need people in a room and a whiteboard to get through these discussions,but I'll try a note anyway:

There is some behavior related to the use of update vectors that requires careful consideration when defining multiple areas of replication rooted at the same entry, or further refining replication at the subentry or replication agreement level.

First, imbedded in the protocol is the notion that an update vector is associated with a replicated area. When starting a replication session, the supplier identifies the replicated area and the consumer responds with its update vector for that area. A consumer server ignores replication updates that have CSNs covered by its update vector. Right now, it is assumed that the replicated area is identified by the DN of an entry that is decorated with the replicationContext auxiliary class. That could be changed, but right now, it happens that the update vector is associated with a replicaSubentry, and each replica is represented by a single replicaSubentry immediately subordinate to the replicationContext. I think most people expect that each server corresponds to exactly one replica and replicaSubentry.

If I have all this right, then it follws that each server has one update vector associated with each replicationContext entry.

Second, purge processing makes use of the update vectors. A server can purge meta-data based on a purge vector that is the minimum of all the update vectors for a given replicated area. Currently, this would be the update vectors associated with each replicasubentry beneath a replicationContext.

Consider the following scenarios...

Scenario 1:

I have three servers, S1, S2, and S3, all containing replicas of replicated area A. There are agreements between all of these servers, and the agreement S2 to S3 has a subtreespecification (or other refinement). A series of changes, C1 (CSN = T1-1) and C2 (CSN=T1-2), is made at S1, such that C1 is outside the subtreespecification attached to the S2 to S3 agreement. Finally, lets assume that scheduling of replication is such that S1 replicates to S2, then S2 replicates to S3, and then S1 replicates to S3.

- S1 replicates to S2: S1 replicates both C1 and C2 to S2. S2 sets its update vector to <T1-2, 0, 0> reflecting that it has received changes through T1-2 originating at S1.

- S2 replicates to S3: S2 replicates C2 to S3, but not C1 (due to subtreespecification on the agreement). S3 sets its update vector to <T1-2, 0, 0>.

- S1 replicates to S3. S3 sends its update vector to S1. S1 notes that S3 has seen all changes through T1-2, and sends nothing. S3 does not receive change C1.

Based on this, I believe that we cannot allow refinements on agreements.


Scenario 2:

I have three servers, S1, S2, and S3, all containing replicated area A. However, the subentry for S2 has a subtree specification that excludes some portion of the area. There are agreements between all these servers. A series of changes, C1 (CSN=T1-1 and C2 (CSN = T1-2) is made at S1 such that C1 is outside of the subtree specification for S2. Finally, lets assume that scheduling of replication is such that S1 replicates to S2, then S2 replicates to S3, and then S1 replicates to S3.

- S1 replicates to S2. S1 does not replicate C1 to S2 (not within the S2's subtree specification), S1 does replicate C2. S2 sets its update vector to <T1-2, 0, 0>

- S2 replicates to S3. S2 sends C2 to S3. S3 sets its update vector to <T1-2, 0, 0>.

- S1 replicates to S3. S3 sends its update vector to S1. S1 notes that S3 has seen changes through T1-2 and sends nothing. S3 does not ever receive change C1.

Based on this, I believe that S2 cannot be allowed to replicate to S3 -- Replica S2 cannot act as a supplier to replica S3 if S2 is a proper subset of S3. One alternative is that S2 accept changes outside its subtree specification and that it replicate them, but does not store them in its DIT. I don't imagine that flying well.

Scenario 3:

Take scenario two, but make a series of changes at S1 -- C1, C2 ... , such that only C1 falls within the subtree specification for S2.

- S1 replicates to S2. S1 sends C1, but not C2...Cn. S2 sets its update vector to <T1-1, 0, 0>

- S2 cannot replicate to S3 (S2 is a subset of S3).

- S1 replicates to S3. S3 sends its update vector to S1, and S1 sends C1...Cn to S3. S3 sets its update vector to <T1-n, 0, 0>

- S1 does purge processing. It notes that its copy of the update vector for S2 has T1-1. No changes after T1-1 are purged until a change is made at S1 that falls within the subtree specification for S2. This violates the requirement that meta-data cannot grow without bound. One alternative is that S2 accept all changes for purposes of setting the updatde vector properly, but that S2 does not store or replicate changes not within its subtree specification. Once again, I don't see this flying.

This suggests that S1 cannot act as a supplier to S2 if the subtree specifications for S1 and S2 are not the same. That doesn't make sense: if S1 is a superset of S2, as is the case here, it ought to be able to act as a supplier, but the current architecture seems to prevent that.


Where next?

I think we need a few things to make overlapping areas of replication work [or we can disallow it]:

- We need a way to define/identify each of the areas of replication. replicationContext objectclass doesn't cut it if two areas can have the same root. Subtree specification as part of a subentry (as opposed to a referenced specification) pretty much makes each subentry its own area of replication, which might simplify to "no replication". A separate object, as you suggest, seems to make the most sense.

- We need a way to associate an update vector with each area of replication, where two areas of replication rooted at the same entry requires two update vectors. Update vectors are an attribute of replicaSubentries. I don't see anything in InfoMod which would prevent there being multiple subentries representing the same physical server, so one solution would be to create separate replica subentries for each area of replication that a server participates in.


John McMeeking

"Ed Reed" <eer@OnCallDBA.COM>




          "Ed Reed" <eer@OnCallDBA.COM>
          Sent by: owner-ietf-ldup@mail.imc.org

          02/26/2002 09:04 AM



To: <steven.legg@adacel.com.au>, <rvh@qsun.mt.att.com>
cc: <ietf-ldup@imc.org>
Subject: RE: Replica Management - subtreespecification attribute



I can't tell if concensus was reached on this or not, so I'll bring it up again...

The purpose of placing the subtree specification, along with other scoping
information, onto the replicaSubentry was precisely to create a single entry
that would define the replication context.

The purpose of allowing additional scoping information to refine what is
to be passed along certain replicationAgreements between particular
replicas was to control the flow of changes across certain links in the
replica topology. By refinement, I mean further contraint. ReplicaAgreements
inherit, by subordination in the namespace, the knowledge about
what entries and attributes are contained in the replica they're subordinate
to, and to which they refer (by the very DN syntax method you suggest).

If my proposed model of name subordination is abandoned for replicaAgreements,
then of course, there will need to be a DN reference to the second endpoint of
the replicaAgreement association (falling into DEN-eese, here). Or to all of them,
if it's to be multivalued.

Tim - have we decided to move away from hierarchical subentries, so as to
more completely and "purely" embrace the X.501 subentry syntax?

If so, you'll wind up with a "bag" of replicaSubentries, together with a "bag"
of replicationAgreements, all necessarily shared/known by all replicas, with
some arbitrary graph where replicaSubentries are nodes of the graph and
replicationAgreements are the edges. It will then be encombant on
administrators (and their tools) to ensure that the graph remains connected,
that there are no black holes (replicaSubentries which are updateable but
have no outbound path of propagating changes to others), etc. In otherwords,
that there remains a "correct" graph, for some definition of "correct".

I must say I dislike designs that place the responsibility for insuring "correct"
deployment on the administrators. I much prefer designs which create
systems that are correct to begin with, and that can then be broken, if
necessary, with enough mule-headed persistance of those administrators.

Anyway.

Rick - I think your desire for an entry, somewhere, that describes the
replication context (scope) that will be shared by all the replicaSubentries
(and possibly refined by them) is a good one. In the absense of a "primary"
replica (my preferred method of solving this problem), I suggest that a
subentry be defined that explicitly is used to designate the anchor point
for the ldup administrative area that coincides with the replication context.

For clarity, here, I reproduce from memory what I mean by those words...

A replication context is a partion of the DIT for which there are one or
more replicas. Each replica is represented by a replicationSubentry
immediately subordinate to the base entry of the replication context.
Replicas of the replication context may be full or partial. If they are
administratively constrained to hold less than the full replication context
(ie, all the entries and all their attributes in the partion of the DIT
represented by the replication context), the refinements (constraints)
for each replica are represented by filters on the respective replicaSubentry
for that replica. Note that I'm explicitly using terminology here to
preclude the notion that a replica holds MORE than ALL the entries
and attributes of the DIT, because that seems nonsensical. The data in the
DIT is the data in the DIT.

(Aside - if the replica context EXPLICITLY
lists the entries or attributes, by including filters in its very definition, then
it is effectively PROHIBITING subordinate replicas from holding information
not permitted in those filters. On the other hand, if it's not prohibited,
as would be the case when there are no filters on the replica context
definition, then subordinate replicas MIGHT define schema elements
locally that THEY can hold, but which cannot be held by other replicas
unless the changes to the schema can be propagated via LDUP - which
may or may not be possible, depending on the replication agreements
and constraints defined on those other replicas).

As aluded to, above, replicationAgreements, which document the
dataflow between replicas, may themselves have constraints as to
the entries and/or attributes which may be passed across them. Again,
though, those constraints, if present, cannot by definition exceed the
set of entries and attributes permitted by replica context definition (however
it is represented). So, again, if the replica context definition is permissive,
subordinate replicas and their replicationAgreements can create local
extensions of the schema they share among themselves. But if
explicitly defined through constraints, the replica context schema definition
cannot be expanded upon in ways to permit in a replica or replicationAgreement
what is prohibited by the replica context definition.

Make sense?

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note: Area code is 585

>>> "Steven Legg" <steven.legg@adacel.com.au> 01/28/02 11:45PM >>>


Rick,

Richard V Huber wrote:
> We noted in a previous email that, to allow overlapping areas of
> replication, we feel that an area of replication is defined by a
> replicaSubentry. The replicaSubentry defines the boundary of the area
> via the subtreespecification attribute.

Note that a subtree specification identifies a collection of entries,
but not a subset of the attributes within them. That is, it specifies the
sparseness of a partial replica. Something else in addition to the subtree
specification is required to specify the fractionalness of a partial
replica,
i.e. the attributeExclusionFilter and attributeInclusionFilter attributes.

Regarding terminology, you appear to be using "area of replication" to mean
some part, possibly but not necessarily all, of the information in a
replication
context. Thus a single replication context can have more than one area
of replication within its scope. This is what I assume it means, however
areas of replication (a.k.a replication areas) are not defined in the
architecture and model drafts and tend to be used as synonyms for
"replication context".


> Because a subtreespecification may need to be shared across a
> number of
> subentries (e.g. all the replicaSubentries that refer to a common area
> of replication), we would like to have a single subtreespecification
> that can be referenced from multiple subentries. Accordingly, we
> would like to change the subentry objectclass to use
> subtreeSpecificationDN and allow the subtree specification to
> be stored
> as a separate entry which can be referenced as needed.

This separate (sub?)entry would contain the attributeExclusionFilter and
attributeInclusionFilter attributes as well.

An alternative to a subtreeSpecificationDN attribute would be to place
the replica subentries subordinate to the (sub)entry describing their
area of replication.

Either way, I would support making such a change to the information model.

Regards,
Steven

>
> This may be useful in other cases where a single subtreespecification
> needs to be used consistently in several places.
>nis effectively PROHIBITING subordinate r
> Rick Huber
> John McMeeking
> Ryan Moats
>



--1__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B-- --0__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE1FFDFD92A5B8f9e8a93@rchland.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE1FFDFD92A5B8f9e8a93@rchland.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE1FFDFD92A5B8f9e8a93df938690918c09BBE1FFDFD92A5B-- From owner-ietf-ldup@mail.imc.org Wed Feb 27 17:41:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22921 for ; Wed, 27 Feb 2002 17:41:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RMWue08442 for ietf-ldup-bks; Wed, 27 Feb 2002 14:32:56 -0800 (PST) Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RMWti08438 for ; Wed, 27 Feb 2002 14:32:56 -0800 (PST) Received: from D7ST2111 ([141.158.243.173]) by out006.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020227223219.NJSL18285.out006.verizon.net@D7ST2111> for ; Wed, 27 Feb 2002 16:32:19 -0600 Reply-To: From: "Chris Apple" To: Subject: FW: LDUP engineering group on access control Date: Wed, 27 Feb 2002 17:32:03 -0500 Message-ID: <002101c1bfde$969d2310$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C1BFB4.ADC71B10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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_0022_01C1BFB4.ADC71B10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0023_01C1BFB4.ADC71B10" ------=_NextPart_001_0023_01C1BFB4.ADC71B10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FYI. Ed Reed will be joining the list of folks below in addressing the access control needs for LDUP. I would also like to invite Steven Legg to participate as an active member of the Design Team for LDUP Access Control since he has chosen to publish a couple of individual contribution drafts on this topic recently. After much deliberation over language in various charter proposals, John and I feel that the best way that this topic can be handled in a revised LDUP WG charter is to replace all details of prior proposals related to this topic with text that says we are chartering an official, WG-endorsed Design Team for LDUP Access Control to come up with a plan for and possibly draft specifications for the WG to consider. The basic notion is that the WG needs to address a minimum ACM for LDUP implementation interoperability. (Not the exact words I'll propose, but you get the idea). RFC 2418, covering WG guidelines, supports the creation of such teams: 6.5. Design teams It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole. John and I would like for the Design Team to settle on a "mini-charter" for this work. I plan to include in a revised WG charter proposal, a milestone that this group of volunteers will present a proposed "mini-charter" at the upcoming working group meeting in Minneapolis. This "mini-charter" MUST define a scope for the team's work (what you are and are not seeking to address), and SHOULD include a tentative list of milestones and deliverables for the WG to consider. Those deliverables would not be added to the WG charter explicitly until consensus is reached that they should and the ADs approve such actions. Since I'm still among the unemployed (but a few qualified leads in the pipeline lately :), I have the cycles to help out productively and would like to be included in the pre-Minneapolis discussions that the Design Team for LDUP Access Control has. My schedule is more or less wide open for conference calls if that's what we'd like to do. Also, I plan to be in Minneapolis as early as 3/16 and am largely free to meet face-to-face about the topic while in town. Phone contact information for me is available in the attached vCard. Design Team on LDUP Access Control membership: Tim Hahn - (hahnt@us.ibm.com) - IBM Matt Hirsch (mhirsch@anassoc.com) - NSA James Benedict (james.benedict@home.com) - no affiliation given Ed Reed Steven Legg (if available) Chris Apple christopher.apple@verizon.net -----Original Message----- From: Timothy Hahn [mailto:hahnt@us.ibm.com] Sent: Thursday, January 10, 2002 10:36 AM To: christopher.apple@verizon.net Subject: LDUP engineering group on access control Chris, Has this engineering group been set up yet? From my append to the mailing list, I have heard responses (offering to participate) from: Tim Hahn - (hahnt@us.ibm.com) - IBM Matt Hirsch (mhirsch@anassoc.com) - NSA James Benedict (james.benedict@home.com) - no affiliation given Do you know of others? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 ------=_NextPart_001_0023_01C1BFB4.ADC71B10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message

FYI.=20 Ed Reed will be joining the list of folks below in addressing=20 the
access=20 control needs for LDUP. I would also like to invite Steven=20 Legg
to=20 participate as an active member of the Design Team for = LDUP
Access=20 Control since he has chosen to publish a couple of=20 individual
contribution drafts on this topic=20 recently.
 
After=20 much deliberation over language in various charter=20 proposals,
John=20 and I feel that the best way that this topic can be = handled
in a=20 revised LDUP WG charter is = to replace = all details of=20 prior proposals
related to this topic with text that = says we are=20 chartering an official,
WG-endorsed Design Team = for LDUP Access=20 Control to come up
with a=20 plan for and possibly draft specifications for the WG to=20 consider.
The=20 basic notion is that the WG needs to address a = minimum
ACM=20 for LDUP implementation interoperability. (Not the exact=20 words
I'll=20 propose, but you get the idea).
 
RFC=20 2418, covering WG guidelines, supports the=20 creation
of=20 such teams:
 
6.5. Design=20 teams

   It is often useful, and perhaps inevitable, = for a=20 sub-group of a
   working group to develop a proposal to = solve a=20 particular problem.
   Such a sub-group is called a design=20 team.  In order for a design team
   to remain small = and=20 agile, it is acceptable to have closed membership
   and = private=20 meetings.  Design teams may range from an informal = chat
  =20 between people in a hallway to a formal set of expert volunteers=20 that
   the WG chair or AD appoints to attack a = controversial=20 problem.  The
   output of a design team is always = subject to=20 approval, rejection or
   modification by the WG as a=20 whole.
 
John=20 and I would like for the Design Team to settle on a "mini-charter" for=20
this=20 work. I plan to include in a revised WG charter proposal,=20 a milestone
that=20 this group of volunteers will present a = proposed=20 "mini-charter"
at the=20 upcoming working group meeting in Minneapolis. This=20 "mini-charter"
MUST=20 define a scope for the team's work (what you are and are=20 not
seeking to address), and = SHOULD include a=20 tentative list of milestones and
deliverables for the WG to = consider.=20 Those deliverables would not be added
to the=20 WG charter explicitly until consensus is reached that = they should=20 and
the=20 ADs approve such actions. Since I'm still among the = unemployed (but=20 a
few=20 qualified leads in the pipeline lately :), I have the cycles = to help=20 out productively
and=20 would like to be included in the pre-Minneapolis discussions that = the=20 Design
Team=20 for LDUP Access Control has. My schedule is more or=20 less
wide=20 open for conference calls if that's what we'd like to do. Also, I plan=20 to
be in=20 Minneapolis as early as 3/16 and am largely free to meet=20 face-to-face
about=20 the topic while in town. Phone contact information for me is available=20 in
the=20 attached vCard.
 
Design=20 Team on LDUP Access Control membership:
 
Tim Hahn - (hahnt@us.ibm.com) - IBM =
Matt Hirsch (mhirsch@anassoc.com) -=20 NSA 
James = Benedict=20 (james.benedict@home.com) - no affiliation=20 given
Ed=20 Reed
Steven Legg (if=20 available)

Chris = Apple

christopher.apple@verizon.net

-----Original Message-----
From: Timothy Hahn=20 [mailto:hahnt@us.ibm.com]
Sent: Thursday, January 10, 2002 = 10:36=20 AM
To: christopher.apple@verizon.net
Subject: LDUP=20 engineering group on access control


Chris,

Has=20 this engineering group been set up yet?

From my append to the mailing list, I have heard responses = (offering to=20 participate) from:

   =20     Tim Hahn - (hahnt@us.ibm.com) - IBM
        Matt Hirsch = (mhirsch@anassoc.com) - NSA
  =    =20   James Benedict (james.benedict@home.com) - no=20 affiliation given

Do you = know of=20 others?

Regards,
Tim=20 Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy=20 Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388   =  =20 tie-line: 8/852.6388
fax: 607.752.3681
 ------=_NextPart_001_0023_01C1BFB4.ADC71B10-- ------=_NextPart_000_0022_01C1BFB4.ADC71B10 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0022_01C1BFB4.ADC71B10-- From owner-ietf-ldup@mail.imc.org Wed Feb 27 19:17:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25518 for ; Wed, 27 Feb 2002 19:17:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1S04Gm10405 for ietf-ldup-bks; Wed, 27 Feb 2002 16:04:16 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1S04Ei10401 for ; Wed, 27 Feb 2002 16:04:14 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1S04CC86456; Thu, 28 Feb 2002 00:04:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020227150543.0177ec88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 16:04:13 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: FW: LDUP engineering group on access control Cc: In-Reply-To: <002101c1bfde$969d2310$0200a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, It is not clear to me what the purpose of this design team is. If it sole purpose is to make suggestions regarding a charter revision, that's fine. However, a number of your statements imply to me that this design team is to (or may at its choosing) undertake LDAP ACM engineering work (including producing I-Ds). The LDUP WG is not chartered to undertake work in this area at present. I ask that you provide a clear terse mission statement for this design team. Thanks, Kurt At 02:32 PM 2002-02-27, Chris Apple wrote: >FYI. Ed Reed will be joining the list of folks below in addressing the >access control needs for LDUP. I would also like to invite Steven Legg >to participate as an active member of the Design Team for LDUP >Access Control since he has chosen to publish a couple of individual >contribution drafts on this topic recently. > >After much deliberation over language in various charter proposals, >John and I feel that the best way that this topic can be handled >in a revised LDUP WG charter is to replace all details of prior proposals >related to this topic with text that says we are chartering an official, >WG-endorsed Design Team for LDUP Access Control to come up >with a plan for and possibly draft specifications for the WG to consider. >The basic notion is that the WG needs to address a minimum >ACM for LDUP implementation interoperability. (Not the exact words >I'll propose, but you get the idea). > >RFC 2418, covering WG guidelines, supports the creation >of such teams: > >6.5. Design teams > > It is often useful, and perhaps inevitable, for a sub-group of a > working group to develop a proposal to solve a particular problem. > Such a sub-group is called a design team. In order for a design team > to remain small and agile, it is acceptable to have closed membership > and private meetings. Design teams may range from an informal chat > between people in a hallway to a formal set of expert volunteers that > the WG chair or AD appoints to attack a controversial problem. The > output of a design team is always subject to approval, rejection or > modification by the WG as a whole. > >John and I would like for the Design Team to settle on a "mini-charter" for >this work. I plan to include in a revised WG charter proposal, a milestone >that this group of volunteers will present a proposed "mini-charter" >at the upcoming working group meeting in Minneapolis. This "mini-charter" >MUST define a scope for the team's work (what you are and are not >seeking to address), and SHOULD include a tentative list of milestones and >deliverables for the WG to consider. Those deliverables would not be added >to the WG charter explicitly until consensus is reached that they should and >the ADs approve such actions. Since I'm still among the unemployed (but a >few qualified leads in the pipeline lately :), I have the cycles to help out productively >and would like to be included in the pre-Minneapolis discussions that the Design >Team for LDUP Access Control has. My schedule is more or less >wide open for conference calls if that's what we'd like to do. Also, I plan to >be in Minneapolis as early as 3/16 and am largely free to meet face-to-face >about the topic while in town. Phone contact information for me is available in >the attached vCard. > >Design Team on LDUP Access Control membership: > >Tim Hahn - (hahnt@us.ibm.com) - IBM >Matt Hirsch (mhirsch@anassoc.com) - NSA >James Benedict (james.benedict@home.com) - no affiliation given >Ed Reed >Steven Legg (if available) > >Chris Apple > >christopher.apple@verizon.net >-----Original Message----- >From: Timothy Hahn [mailto:hahnt@us.ibm.com] >Sent: Thursday, January 10, 2002 10:36 AM >To: christopher.apple@verizon.net >Subject: LDUP engineering group on access control > > >Chris, > >Has this engineering group been set up yet? > >From my append to the mailing list, I have heard responses (offering to participate) from: > > Tim Hahn - (hahnt@us.ibm.com) - IBM > Matt Hirsch (mhirsch@anassoc.com) - NSA > James Benedict (james.benedict@home.com) - no affiliation given > >Do you know of others? > >Regards, >Tim Hahn > >Internet: hahnt@us.ibm.com >Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) >phone: 607.752.6388 tie-line: 8/852.6388 >fax: 607.752.3681 From owner-ietf-ldup@mail.imc.org Wed Feb 27 21:36:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00009 for ; Wed, 27 Feb 2002 21:36:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1S2PYQ13208 for ietf-ldup-bks; Wed, 27 Feb 2002 18:25:34 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1S2PWi13202 for ; Wed, 27 Feb 2002 18:25:32 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.us.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA184188; Wed, 27 Feb 2002 21:21:39 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1S2OoK75838; Wed, 27 Feb 2002 21:24:50 -0500 Subject: Re: Replication Management - Some questions on the Information Model To: ietf-ldup@imc.org Cc: eer@OnCallDBA.COM, "John McMeeking" , rmoats@lemurnetworks.net, rvh@qsun.mt.att.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Wed, 27 Feb 2002 21:19:26 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V5010_0212_dev00 |February 14, 2002) at 02/27/2002 09:24:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rick, So, this is probably too long in coming up with a reply, but I'll take a stab at it anyway. See ... below. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 rvh@qsun.mt.att.c om (Richard V To: ietf-ldup@imc.org Huber) cc: eer@OnCallDBA.COM, Timothy Hahn/Endicott/IBM@IBMUS, John Sent by: McMeeking/Rochester/IBM@IBMUS, rmoats@lemurnetworks.net, rvh@qsun.mt.att.com owner-ietf-ldup@m Subject: Replication Management - Some questions on the Information Model ail.imc.org 01/23/2002 11:52 PM A few questions on InfoMod (draft -04). 1. In Section 8.3.3 (definition of the replicaAgreementSubentry objectclass), why is replicaDN a MAY rather than a MUST? The replication agreement is useless without a replicaDN, and the text states that the replicaAgreementSubentry is ignored if the replicaDN is missing, so why not just require that it be there? I believe we left it as optional so that for servers that implement "referential integrity" of distinguished name attributes, that values for this attribute could be deleted (indeed, the whole attribute can be deleted without violating the schema for the entry. 2. There are a number of attributes listed as NO-USER-MODIFICATION. They are (with section number where they are defined): attributeExclusionFilter (Section 8.2.4) attributeInclusionFilter (Section 8.2.5) replicationStatus (Section 8.2.7) replicaType (Section 8.2.8) updateVector (Section 8.2.9) secondsToWaitDefault (Section 8.2.18) secondsToWait1 (Section 8.2.19) secondsToWait2 (Section 8.2.21) Do all of these attributes really need to be unmodifiable? For adminstrative purposes, we can see some cases where replicaType or updateVector need to be changed (though only by administrators). And it's not clear to us why the filter and secondsToWait attributes need to be unmodifiable in any case. Would availability of access controls make some of these questions moot? Are some of these attributes marked NO-USER-MODIFICATION because they should only be changed by administrators? I will assert that the answer to the last question is yes. Now, in looking at the draft, I tend to agree now that attributeExclusionFilter, attributeInclusionFilter, replicaType, secondsToWaitDefault, secondsToWait1, and secondsToWait2 need not be NO-USER-MODIFICATION. UpdateVector, however, I feel should remain NO-USER-MODIFICATION as direct modification of this information seems disasterous. I would rather see some sort of extended operation or control be defined for doing surgery on the update vector. 3. The replicationStatus attribute is in the replicaAgreementSubentry. The attribute is optional and the replicationAgreementSubentry itself is optional. This means that there is no standard place where replication status can be found. Shouldn't there be some known place to check for status? Should we move replicationStatus to the replicaSubentry and make it a MUST instead of a MAY? Or do we need to define some other place where status can always be checked? The intent of the status value was to give some place for administration tools to look for status relative to the replicationAgreement between the supplier and consumer. The values were meant to represent the last known status as seen by the supplier the last time a replication session was performed to the consumer. As such, I think it still belongs in the replicationAgreementSubentry. It is a valid question as to where to check for status - in general. I suspect that the administration application(s) will have to connect to multiple (if not all) servers in the replication topology to determine each one's replication "status" so that the real "status" of replication can be discerned through correlation of each server's information. This is not an answer, just pointing out that where to report status is a "thorny" issue. Perhaps the replicaSubentry could hold a "replicaStatus" as well? 4. The replicationAgreementSubentry is optional. But the replicationCredentialsDN is in the replicationAgreementSubentry. This means that in the simple case described in Section 9, replication is unauthenticated. Is that really what we want? No, I don't think so :-). I don't have a good answer for this one yet - I'll have to discuss it with the other authors (Ed any ideas here?) Rick Huber John McMeeking Ryan Moats From owner-ietf-ldup@mail.imc.org Thu Feb 28 01:38:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05094 for ; Thu, 28 Feb 2002 01:38:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1S6HgW16219 for ietf-ldup-bks; Wed, 27 Feb 2002 22:17:42 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1S6Hei16212 for ; Wed, 27 Feb 2002 22:17:40 -0800 (PST) Received: (qmail 31096 invoked from network); 28 Feb 2002 06:18:21 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 28 Feb 2002 06:18:21 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" , , Subject: RE: Basic Access Control for LDAP Date: Thu, 28 Feb 2002 17:16:38 +1100 Message-ID: <007e01c1c01f$7b9f2130$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > One question from reading the drafts (for now) - > > What constitutes a "user" for the purpose of ACI UserClasses > value allUsers? In the first instance it is anyone/anything who manages to bind in, regardless of their authorization identity, but it is qualified by the AuthenticationLevel and whether a permission is being granted or denied. For a permission being granted: 1) If the AuthenticationLevel is "none" then allUsers includes everyone, regardless of authorization identity, anonymous included. 2) If the AuthenticationLevel is "simple" then allUsers includes all users who have authenticated with at least a user name and password. Anonymous users and users who have not been authenticated are excluded. 3) If the AuthenticationLevel is "strong" then allUsers includes all users who have authenticated with strong credentials, e.g digital signatures. Anonymous users, unauthenticated users and password authenticated users are excluded. For a permission being denied, allUsers includes everyone, regardless of authorization identity and authentication level. Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Feb 28 06:45:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17175 for ; Thu, 28 Feb 2002 06:45:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SBamO22648 for ietf-ldup-bks; Thu, 28 Feb 2002 03:36:48 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SBali22644 for ; Thu, 28 Feb 2002 03:36:47 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Thu, 28 Feb 2002 06:34:05 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 28 Feb 2002 06:33:40 -0700 From: "Ed Reed" To: , , Subject: RE: Basic Access Control for LDAP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1SBali22645 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Actually, my question is a bit more basic - Does allUsers include entries of any and all object classes, or only object classes derived from "person", or only "person"s with, say, a password attribute present, or some other definition? Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Steven Legg" 02/28/02 01:16AM >>> Ed, Ed Reed wrote: > One question from reading the drafts (for now) - > > What constitutes a "user" for the purpose of ACI UserClasses > value allUsers? In the first instance it is anyone/anything who manages to bind in, regardless of their authorization identity, but it is qualified by the AuthenticationLevel and whether a permission is being granted or denied. For a permission being granted: 1) If the AuthenticationLevel is "none" then allUsers includes everyone, regardless of authorization identity, anonymous included. 2) If the AuthenticationLevel is "simple" then allUsers includes all users who have authenticated with at least a user name and password. Anonymous users and users who have not been authenticated are excluded. 3) If the AuthenticationLevel is "strong" then allUsers includes all users who have authenticated with strong credentials, e.g digital signatures. Anonymous users, unauthenticated users and password authenticated users are excluded. For a permission being denied, allUsers includes everyone, regardless of authorization identity and authentication level. Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Feb 28 07:05:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17503 for ; Thu, 28 Feb 2002 07:05:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SBugh23405 for ietf-ldup-bks; Thu, 28 Feb 2002 03:56:42 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SBufi23401 for ; Thu, 28 Feb 2002 03:56:41 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Thu, 28 Feb 2002 06:53:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 28 Feb 2002 06:53:44 -0700 From: "Ed Reed" To: , Cc: , , Subject: Re: Replication Management - Some questions on the Information Model Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1SBugi23402 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'll throw my original intent into comments , too ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Timothy Hahn" 02/27/02 09:19PM >>> Rick, So, this is probably too long in coming up with a reply, but I'll take a stab at it anyway. See ... below. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 rvh@qsun.mt.att.c om (Richard V To: ietf-ldup@imc.org Huber) cc: eer@OnCallDBA.COM, Timothy Hahn/Endicott/IBM@IBMUS, John Sent by: McMeeking/Rochester/IBM@IBMUS, rmoats@lemurnetworks.net, rvh@qsun.mt.att.com owner-ietf-ldup@m Subject: Replication Management - Some questions on the Information Model ail.imc.org 01/23/2002 11:52 PM A few questions on InfoMod (draft -04). 1. In Section 8.3.3 (definition of the replicaAgreementSubentry objectclass), why is replicaDN a MAY rather than a MUST? The replication agreement is useless without a replicaDN, and the text states that the replicaAgreementSubentry is ignored if the replicaDN is missing, so why not just require that it be there? I believe we left it as optional so that for servers that implement "referential integrity" of distinguished name attributes, that values for this attribute could be deleted (indeed, the whole attribute can be deleted without violating the schema for the entry. Original intent - specifically to deal with the case when the replica pointed to by a replication agreement is deleted. If the DSA enforces referential integrity of DN pointers by deleting the DN pointer when the thing it points to is deleted, then the absence of the pointer makes the agreement "incomplete", but the agreement doesn't go away (there's no "foreign key" relationship in LDAP to force the deletion of the entry that refers to the deleted entry. This was my way of handling that. There may be others, but this is the approach I took. 2. There are a number of attributes listed as NO-USER-MODIFICATION. They are (with section number where they are defined): attributeExclusionFilter (Section 8.2.4) attributeInclusionFilter (Section 8.2.5) replicationStatus (Section 8.2.7) replicaType (Section 8.2.8) updateVector (Section 8.2.9) secondsToWaitDefault (Section 8.2.18) secondsToWait1 (Section 8.2.19) secondsToWait2 (Section 8.2.21) Do all of these attributes really need to be unmodifiable? For adminstrative purposes, we can see some cases where replicaType or updateVector need to be changed (though only by administrators). And it's not clear to us why the filter and secondsToWait attributes need to be unmodifiable in any case. Would availability of access controls make some of these questions moot? Are some of these attributes marked NO-USER-MODIFICATION because they should only be changed by administrators? I will assert that the answer to the last question is yes. Now, in looking at the draft, I tend to agree now that attributeExclusionFilter, attributeInclusionFilter, replicaType, secondsToWaitDefault, secondsToWait1, and secondsToWait2 need not be NO-USER-MODIFICATION. UpdateVector, however, I feel should remain NO-USER-MODIFICATION as direct modification of this information seems disasterous. I would rather see some sort of extended operation or control be defined for doing surgery on the update vector. The intent was that ONLY administrative tools should be modifying the configuration attributes, not USER tools. I envisioned a control being used by the administrative tools to indicate that priviledged operations (over ride NO-USER-MODIFICATION flags, for instance, or creation of entries with given creation UUIDs, for instance). But mainly I wanted plain users not to be able to modify these attributes that are crucial to the correct operation of the distributed directory. 3. The replicationStatus attribute is in the replicaAgreementSubentry. The attribute is optional and the replicationAgreementSubentry itself is optional. This means that there is no standard place where replication status can be found. Shouldn't there be some known place to check for status? Should we move replicationStatus to the replicaSubentry and make it a MUST instead of a MAY? Or do we need to define some other place where status can always be checked? The intent of the status value was to give some place for administration tools to look for status relative to the replicationAgreement between the supplier and consumer. The values were meant to represent the last known status as seen by the supplier the last time a replication session was performed to the consumer. As such, I think it still belongs in the replicationAgreementSubentry. It is a valid question as to where to check for status - in general. I suspect that the administration application(s) will have to connect to multiple (if not all) servers in the replication topology to determine each one's replication "status" so that the real "status" of replication can be discerned through correlation of each server's information. This is not an answer, just pointing out that where to report status is a "thorny" issue. Perhaps the replicaSubentry could hold a "replicaStatus" as well? I could argue that the usual "known place to check for status" is the logs of the servers involved. The purpose of this was, as Tim says, to make it easier in the distributed environment, for a remote operator to quickly check the "health" of the replication system, and to detect failures that need further investigation. There was no intent to provide full diagnostic support here - only the report of success or failure (and reason code if a failure) of the last attempt at replication. 4. The replicationAgreementSubentry is optional. But the replicationCredentialsDN is in the replicationAgreementSubentry. This means that in the simple case described in Section 9, replication is unauthenticated. Is that really what we want? No, I don't think so :-). I don't have a good answer for this one yet - I'll have to discuss it with the other authors (Ed any ideas here?) The notion I had (hey, it doesn't have to have been a GOOD notion!) was that the absence of a replication agreement would indicate that all defaults were to be taken between this replica and other replicas... probably something like "send changes after a short countdown counter expires to all other replicas using the public key certificate identity associated with the originating DSA to establish a mutual authentication TLS session to the DSA holding each of the other replicas defined, one at a time". In other words, use a default authentication mechanism that doesn't require configuration information from the replication agreement (the certificate on the entry in the directory representing the DSA holding the replica), on some default schedule. I explicitly did NOT expect that ANY replication session EVER would be conducted anonymously, and I DO NOT think that anonymous replication sessions SHOULD be allowed, at all, in contravention of my reading of requirement S3 - "The protocol MUST also support the initialization of anonymous replication sessions." Which I needed to ask you (Rick) about, anyway! Do I misunderstand the intent of that requirement, or am I correct that I simply opose it alltogether? Rick Huber John McMeeking Ryan Moats From owner-ietf-ldup@mail.imc.org Thu Feb 28 07:14:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18642 for ; Thu, 28 Feb 2002 07:14:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SC67k23584 for ietf-ldup-bks; Thu, 28 Feb 2002 04:06:07 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SC66i23580 for ; Thu, 28 Feb 2002 04:06:06 -0800 (PST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.us.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA85556 for ; Thu, 28 Feb 2002 07:02:46 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay03.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1SC4PK60052 for ; Thu, 28 Feb 2002 07:05:50 -0500 Reply-To: "Timothy Hahn" Subject: Re: Replication Management - Some questions on the Information Model To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Thu, 28 Feb 2002 07:03:53 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V5010_0212_dev00 |February 14, 2002) at 02/28/2002 07:05:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ed, I agree with the comments you made here. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Ed Reed" , M> cc: , , John Sent by: McMeeking/Rochester/IBM@IBMUS owner-ietf-ldup@m Subject: Re: Replication Management - Some questions on the Information Model ail.imc.org 02/28/2002 08:53 AM Please respond to Timothy Hahn I'll throw my original intent into comments , too ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Timothy Hahn" 02/27/02 09:19PM >>> Rick, So, this is probably too long in coming up with a reply, but I'll take a stab at it anyway. See ... below. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 From owner-ietf-ldup@mail.imc.org Thu Feb 28 07:16:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18709 for ; Thu, 28 Feb 2002 07:16:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SC6Kc23592 for ietf-ldup-bks; Thu, 28 Feb 2002 04:06:20 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SC4wi23562 for ; Thu, 28 Feb 2002 04:04:59 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Thu, 28 Feb 2002 07:02:11 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 28 Feb 2002 07:01:55 -0700 From: "Ed Reed" To: , , , Cc: Subject: Question re: requirement S3 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1SC4xi23563 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Uppili and I are working on updating the Architecture document (!) and have a question about requirement S3 - The protocol MUST also support the initialization of anonymous replication sessions. Politely, are you sure? We would much rather strictly prohibit acceptance of LDUP replication sessions over unauthenticated anonymous connections. (of course, there's nothing to prevent someone from trying to initiate one, I suppose, but there certainly ought not be any requirement to accept one). Why is there any reason for any server to ever accept anonymous assertion of replica changes it is supposed to send or receive? Your clarification will be greatly appreciated. In the meantime, the architecture document will continue to require authentication for all replication sessions. Ed and Uppili ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 From owner-ietf-ldup@mail.imc.org Thu Feb 28 09:36:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25111 for ; Thu, 28 Feb 2002 09:36:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SE88O00410 for ietf-ldup-bks; Thu, 28 Feb 2002 06:08:08 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SE86i00406; Thu, 28 Feb 2002 06:08:06 -0800 (PST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.us.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA55298; Thu, 28 Feb 2002 09:04:09 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay03.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1SE79145496; Thu, 28 Feb 2002 09:07:09 -0500 From: "John McMeeking" Subject: Re: Replication Management - Some questions on the Information Model To: "Ed Reed" Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, rmoats@lemurnetworks.net, rvh@qsun.mt.att.com, thahn@stny.rr.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 28 Feb 2002 08:07:00 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 02/28/2002 08:07:22 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBE1FDDFD9621C8f9e8a93df938690918c09BBE1FDDFD9621C" Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=09BBE1FDDFD9621C8f9e8a93df938690918c09BBE1FDDFD9621C Content-type: text/plain; charset=US-ASCII Ed (and others), Here's my thoughts on two responses . I'm okay with the others. John McMeeking 2. There are a number of attributes listed as NO-USER-MODIFICATION. They are (with section number where they are defined): attributeExclusionFilter (Section 8.2.4) attributeInclusionFilter (Section 8.2.5) replicationStatus (Section 8.2.7) replicaType (Section 8.2.8) updateVector (Section 8.2.9) secondsToWaitDefault (Section 8.2.18) secondsToWait1 (Section 8.2.19) secondsToWait2 (Section 8.2.21) Do all of these attributes really need to be unmodifiable? For adminstrative purposes, we can see some cases where replicaType or updateVector need to be changed (though only by administrators). And it's not clear to us why the filter and secondsToWait attributes need to be unmodifiable in any case. Would availability of access controls make some of these questions moot? Are some of these attributes marked NO-USER-MODIFICATION because they should only be changed by administrators? I will assert that the answer to the last question is yes. Now, in looking at the draft, I tend to agree now that attributeExclusionFilter, attributeInclusionFilter, replicaType, secondsToWaitDefault, secondsToWait1, and secondsToWait2 need not be NO-USER-MODIFICATION. UpdateVector, however, I feel should remain NO-USER-MODIFICATION as direct modification of this information seems disasterous. I would rather see some sort of extended operation or control be defined for doing surgery on the update vector. The intent was that ONLY administrative tools should be modifying the configuration attributes, not USER tools. I envisioned a control being used by the administrative tools to indicate that priviledged operations (over ride NO-USER- MODIFICATION flags, for instance, or creation of entries with given creation UUIDs, for instance). But mainly I wanted plain users not to be able to modify these attributes that are crucial to the correct operation of the distributed directory. Perhaps this would be better accomplished via access control, then, with a note in the security section to the affect that: "Because the replication configuration information stored in the directory is crucial to the correct operation of the distributed directory, appropriate access control mechanisms SHOULD be applied." It is reasonable that user modification of the updateVector require a special mechanism, and thus be marked as NO-USER-MODIFICATION. 4. The replicationAgreementSubentry is optional. But the replicationCredentialsDN is in the replicationAgreementSubentry. This means that in the simple case described in Section 9, replication is unauthenticated. Is that really what we want? No, I don't think so :-). I don't have a good answer for this one yet - I'll have to discuss it with the other authors (Ed any ideas here?) The notion I had (hey, it doesn't have to have been a GOOD notion!) was that the absence of a replication agreement would indicate that all defaults were to be taken between this replica and other replicas... probably something like "send changes after a short countdown counter expires to all other replicas using the public key certificate identity associated with the originating DSA to establish a mutual authentication TLS session to the DSA holding each of the other replicas defined, one at a time". In other words, use a default authentication mechanism that doesn't require configuration information from the replication agreement (the certificate on the entry in the directory representing the DSA holding the replica), on some default schedule. I explicitly did NOT expect that ANY replication session EVER would be conducted anonymously, and I DO NOT think that anonymous replication sessions SHOULD be allowed, at all, in contravention of my reading of requirement S3 - "The protocol MUST also support the initialization of anonymous replication sessions." Which I needed to ask you (Rick) about, anyway! Do I misunderstand the intent of that requirement, or am I correct that I simply opose it alltogether? I suggest that text be added to clarify that in the absense of replication agreements, the authentication mechanism used is determined by the implementation. Implementations MUST provide a means for specifying the authentication mechanism and credentials that will be used. My reading is that the replicationCredentialsDN is used only by the supplier server; the consumer uses an implementation defined mechanism to define credentials that it accepts for replication (though I don't recall reading that anywhere). The presence or absence of credentials in an [implied] agreement isn't critical, as long as we define what happens in their absence. As to use of anonymous replication, if someone really wants to do that, let them. I wouldn't make it the default set up on the consumer end, though. --0__=09BBE1FDDFD9621C8f9e8a93df938690918c09BBE1FDDFD9621C Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Ed (and others),

Here's my thoughts on two responses <jam></jam>. I'm okay with the others.


John McMeeking


2. There are a number of attributes listed as NO-USER-MODIFICATION.
They are (with section number where they are defined):

attributeExclusionFilter (Section 8.2.4)
attributeInclusionFilter (Section 8.2.5)
replicationStatus (Section 8.2.7)
replicaType (Section 8.2.8)
updateVector (Section 8.2.9)
secondsToWaitDefault (Section 8.2.18)
secondsToWait1 (Section 8.2.19)
secondsToWait2 (Section 8.2.21)

Do all of these attributes really need to be unmodifiable? For
adminstrative purposes, we can see some cases where replicaType or
updateVector need to be changed (though only by administrators).
And it's not clear to us why the filter and secondsToWait
attributes need to be unmodifiable in any case.

Would availability of access controls make some of these questions
moot? Are some of these attributes marked NO-USER-MODIFICATION
because they should only be changed by administrators?
<TJH>
I will assert that the answer to the last question is yes. Now, in
looking at the draft, I tend to agree now that attributeExclusionFilter,
attributeInclusionFilter, replicaType, secondsToWaitDefault,
secondsToWait1, and
secondsToWait2 need not be NO-USER-MODIFICATION. UpdateVector, however,
I feel should remain NO-USER-MODIFICATION as direct modification of this
information seems disasterous. I would rather see some sort of extended
operation
or control be defined for doing surgery on the update vector.
</TJH>

<eer>
The intent was that ONLY administrative tools should be modifying the configuration
attributes, not USER tools. I envisioned a control being used by the administrative
tools to indicate that priviledged operations (over ride NO-USER-MODIFICATION flags,
for instance, or creation of entries with given creation UUIDs, for instance). But
mainly I wanted plain users not to be able to modify these attributes that are
crucial to the correct operation of the distributed directory.
</eer>

<jam>
Perhaps this would be better accomplished via access control, then, with a note in the security section to the affect that:

"Because the replication configuration information stored in the directory is crucial to the correct operation of the distributed directory, appropriate access control mechanisms SHOULD be applied."

It is reasonable that user modification of the updateVector require a special mechanism, and thus be marked as NO-USER-MODIFICATION.
</jam>

4. The replicationAgreementSubentry is optional. But the
replicationCredentialsDN is in the replicationAgreementSubentry.
This means that in the simple case described in Section 9,
replication is unauthenticated. Is that really what we want?
<TJH>
No, I don't think so :-).

I don't have a good answer for this one yet - I'll have to discuss it
with the other authors (Ed any ideas here?)
</TJH>

<eer>
The notion I had (hey, it doesn't have to have been a GOOD notion!)
was that the absence of a replication agreement would indicate that
all defaults were to be taken between this replica and other replicas...
probably something like "send changes after a short countdown counter
expires to all other replicas using the public key certificate identity
associated with the originating DSA to establish a mutual authentication
TLS session to the DSA holding each of the other replicas defined, one
at a time". In other words, use a default authentication mechanism that
doesn't require configuration information from the replication agreement
(the certificate on the entry in the directory representing the DSA
holding the replica), on some default schedule.

I explicitly did NOT expect that ANY replication session EVER would
be conducted anonymously, and I DO NOT think that anonymous
replication sessions SHOULD be allowed, at all, in contravention of
my reading of requirement S3 - "The protocol MUST also support the
initialization of anonymous replication sessions." Which I needed to
ask you (Rick) about, anyway! Do I misunderstand the intent of that
requirement, or am I correct that I simply opose it alltogether?
</eer>

<jam>
I suggest that text be added to clarify that in the absense of replication agreements, the authentication mechanism used is determined by the implementation. Implementations MUST provide a means for specifying the authentication mechanism and credentials that will be used.

My reading is that the replicationCredentialsDN is used only by the supplier server; the consumer uses an implementation defined mechanism to define credentials that it accepts for replication (though I don't recall reading that anywhere). The presence or absence of credentials in an [implied] agreement isn't critical, as long as we define what happens in their absence.

As to use of anonymous replication, if someone really wants to do that, let them. I wouldn't make it the default set up on the consumer end, though.
</jam>
--0__=09BBE1FDDFD9621C8f9e8a93df938690918c09BBE1FDDFD9621C-- From owner-ietf-ldup@mail.imc.org Thu Feb 28 11:01:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00081 for ; Thu, 28 Feb 2002 11:01:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1SFk1E07124 for ietf-ldup-bks; Thu, 28 Feb 2002 07:46:01 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SFiai07083 for ; Thu, 28 Feb 2002 07:44:36 -0800 (PST) Received: from qsun.mt.att.com ([135.16.30.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g1SFgEZ13424; Thu, 28 Feb 2002 10:42:20 -0500 (EST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id KAA29397; Thu, 28 Feb 2002 10:42:08 -0500 Message-ID: <3C7E4FC4.F633CE25@att.com> Date: Thu, 28 Feb 2002 10:41:57 -0500 From: Richard Huber X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ed Reed , "Srinivasan, Uppili" CC: rmoats@coreon.net, rweiser@digsigtrust.com, ejstokes@us.ibm.com, ietf-ldup@imc.org Subject: Re: Question re: requirement S3 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is my recollection of some of the discussion we had among the authors when we added S3. The other authors can chip in if they remember things differently. First, S3 is not intended to require that servers always accept anonymous replication requests. It just says that the protocol needs to support such requests if a given pair of servers is configured to use them. An analogous situation is FTP, where anonymous FTP is supported in the protocol but is turned of on many FTP servers. So when you say "of course, there's nothing to prevent someone from trying to initiate one" it seems that we may already be in agreement. As for the circumstances where it might be useful to have anonymous replication, a set of replicating directory servers on a private net behind a firewall that only lets through LDAP requests would not need authentication among the replicating servers; security in this case has been provided by means outside of LDAP/LDUP. These are the same sorts of situations where the confidentiality features might not be needed. And there may be some situations in setting up a new replica where it is useful to have anonymous replication (see Section 5.1 and 5.1.1 of the MRM draft). There are certainly many situations where anonymous replication is a very BAD idea. It should be disabled in such situations. But it should not be absolutely forbidden in all situations. Rick Huber Ed Reed wrote: > Uppili and I are working on updating the Architecture document (!) and have a question about requirement S3 - The protocol MUST also support the initialization of anonymous replication sessions. > > Politely, are you sure? We would much rather strictly prohibit acceptance of LDUP replication sessions over unauthenticated anonymous connections. (of course, there's nothing to prevent someone from trying to initiate one, I suppose, but there certainly ought not be any requirement to accept one). > > Why is there any reason for any server to ever accept anonymous assertion of replica changes it is supposed to send or receive? > > Your clarification will be greatly appreciated. In the meantime, the architecture document will continue to require authentication for all replication sessions. > > Ed and Uppili > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 585 624 2402 > http://www.Reed-Matthews.COM > Note: Area code is 585 From owner-ietf-ldup@mail.imc.org Thu Feb 28 14:19:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14088 for ; Thu, 28 Feb 2002 14:19:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SJA2314787 for ietf-ldup-bks; Thu, 28 Feb 2002 11:10:02 -0800 (PST) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SJA1i14779 for ; Thu, 28 Feb 2002 11:10:01 -0800 (PST) Received: from D7ST2111 ([141.158.247.29]) by out011.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020228190957.ECKB9330.out011.verizon.net@D7ST2111> for ; Thu, 28 Feb 2002 13:09:57 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: FW: LDUP engineering group on access control Date: Thu, 28 Feb 2002 14:09:52 -0500 Message-ID: <001701c1c08b$82e7c8e0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C1C061.9A11C0E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.0.20020227150543.0177ec88@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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_0018_01C1C061.9A11C0E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It is my intent that the members of the Design Team confer and present a proposal to the WG for a clear, terse mission statement that would bound the scope of their subsequent work, should any such work actually occur in the future. And that in addition, the Design Team will propose a set of milestones/deliverables or their own "mini-charter." The WG would then attempt to achieve consensus on the mission statement and "mini-charter" in the same way that we deal with any other discussion topic. Whether or not that consensus includes adding some or all of those milestones and/or deliverables to the WG charter is a matter that will have to be discussed once we have a clear work program Proposal from the Design Team. So, I suppose you could indeed say that this Design Team, for the time being, is merely going to bound the problem(s) that need to be solved related to Access Control for LDUP and also to suggest a work program that may or may not be added to the WG charter at a later date. Just so that its really clear, here's what's happening: 1) The Design Team will discuss and document a clear mission statement (I called it something like "scope of work" in an earlier e-mail) about what they are specifically seeking to accomplish related to addressing Access Control in the Context of LDUP. 2) The Design Team will discuss and document a proposed work program that seeks to accomplish the mission defined in the mission statement. 3) Results from 1) and 2) will be presented to the WG for consideration at the WG meeting and discussed further on the mailing list. 4) A revised WG Charter, capturing changes discussed on the list and during the last WG meeting will be drafted and posted to the WG Mailing list. It will include a milestone for the formation of a Design Team to determine how access control should be addressed as well as a milestone for their initial report to the WG with proposals consistent with 1) and 2) above. 5) If a consensus can be achieved while discussion mentioned in 3) is taking place that we should add the Design Team's proposal to the WG Charter, we will add the resulting Design Team mission statement to the WG charter proposal along with any deliverables/milestones that will be performed by members of the Design Team going forward. This process has already started via off-list e-mail exchange as is typical with Design Teams. Also, Rick Huber reminded me that he was willing to be a member of the Design Team as well. It was my error in omitting his name from the list of volunteers. Design Team members: please include Rick Huber on all LDUP Access Control Design Team discussion. Chris Apple christopher.apple@verizon.net -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, February 27, 2002 7:04 PM To: christopher.apple@verizon.net Cc: ietf-ldup@imc.org Subject: Re: FW: LDUP engineering group on access control Chris, It is not clear to me what the purpose of this design team is. If it sole purpose is to make suggestions regarding a charter revision, that's fine. However, a number of your statements imply to me that this design team is to (or may at its choosing) undertake LDAP ACM engineering work (including producing I-Ds). The LDUP WG is not chartered to undertake work in this area at present. I ask that you provide a clear terse mission statement for this design team. Thanks, Kurt At 02:32 PM 2002-02-27, Chris Apple wrote: >FYI. Ed Reed will be joining the list of folks below in addressing the >access control needs for LDUP. I would also like to invite Steven Legg >to participate as an active member of the Design Team for LDUP Access >Control since he has chosen to publish a couple of individual >contribution drafts on this topic recently. > >After much deliberation over language in various charter proposals, >John and I feel that the best way that this topic can be handled in a >revised LDUP WG charter is to replace all details of prior proposals >related to this topic with text that says we are chartering an >official, WG-endorsed Design Team for LDUP Access Control to come up >with a plan for and possibly draft specifications for the WG to >consider. The basic notion is that the WG needs to address a minimum >ACM for LDUP implementation interoperability. (Not the exact words I'll >propose, but you get the idea). > >RFC 2418, covering WG guidelines, supports the creation >of such teams: > >6.5. Design teams > > It is often useful, and perhaps inevitable, for a sub-group of a > working group to develop a proposal to solve a particular problem. > Such a sub-group is called a design team. In order for a design team > to remain small and agile, it is acceptable to have closed membership > and private meetings. Design teams may range from an informal chat > between people in a hallway to a formal set of expert volunteers that > the WG chair or AD appoints to attack a controversial problem. The > output of a design team is always subject to approval, rejection or > modification by the WG as a whole. > >John and I would like for the Design Team to settle on a "mini-charter" >for >this work. I plan to include in a revised WG charter proposal, a milestone >that this group of volunteers will present a proposed "mini-charter" >at the upcoming working group meeting in Minneapolis. This "mini-charter" >MUST define a scope for the team's work (what you are and are not >seeking to address), and SHOULD include a tentative list of milestones and >deliverables for the WG to consider. Those deliverables would not be added >to the WG charter explicitly until consensus is reached that they should and >the ADs approve such actions. Since I'm still among the unemployed (but a >few qualified leads in the pipeline lately :), I have the cycles to help out productively >and would like to be included in the pre-Minneapolis discussions that the Design >Team for LDUP Access Control has. My schedule is more or less >wide open for conference calls if that's what we'd like to do. Also, I plan to >be in Minneapolis as early as 3/16 and am largely free to meet face-to-face >about the topic while in town. Phone contact information for me is available in >the attached vCard. > >Design Team on LDUP Access Control membership: > >Tim Hahn - (hahnt@us.ibm.com) - IBM >Matt Hirsch (mhirsch@anassoc.com) - NSA >James Benedict (james.benedict@home.com) - no affiliation given >Ed Reed >Steven Legg (if available) > >Chris Apple > >christopher.apple@verizon.net >-----Original Message----- >From: Timothy Hahn [mailto:hahnt@us.ibm.com] >Sent: Thursday, January 10, 2002 10:36 AM >To: christopher.apple@verizon.net >Subject: LDUP engineering group on access control > > >Chris, > >Has this engineering group been set up yet? > >From my append to the mailing list, I have heard responses (offering to >participate) from: > > Tim Hahn - (hahnt@us.ibm.com) - IBM > Matt Hirsch (mhirsch@anassoc.com) - NSA > James Benedict (james.benedict@home.com) - no affiliation given > >Do you know of others? > >Regards, >Tim Hahn > >Internet: hahnt@us.ibm.com >Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) >phone: 607.752.6388 tie-line: 8/852.6388 >fax: 607.752.3681 ------=_NextPart_000_0018_01C1C061.9A11C0E0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0018_01C1C061.9A11C0E0-- From owner-ietf-ldup@mail.imc.org Thu Feb 28 16:00:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19525 for ; Thu, 28 Feb 2002 16:00:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SKqQ217370 for ietf-ldup-bks; Thu, 28 Feb 2002 12:52:26 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SKqOi17366 for ; Thu, 28 Feb 2002 12:52:24 -0800 (PST) Received: from qsun.mt.att.com ([135.16.157.16]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g1SKmiW04648; Thu, 28 Feb 2002 15:48:44 -0500 (EST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id PAA13703; Thu, 28 Feb 2002 15:48:42 -0500 Message-ID: <3C7E97A0.72252D42@att.com> Date: Thu, 28 Feb 2002 15:48:32 -0500 From: Richard Huber X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Internet Drafts Editor , " =?iso-8859-1?Q?F=E4ltstr=F6m?=, Patrik" , ietf-ldup@imc.org CC: Ryan Moats , Ellen Stokes , Russel Weiser , "Apple, Christopher" , "Strassner, John" Subject: LDUP Requirements Content-Type: multipart/mixed; boundary="------------810D2087DFDB5DE1AA6D02DE" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------810D2087DFDB5DE1AA6D02DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Internet Drafts Editor - Please publish the attached draft as draft-ietf-ldup-replica-req-11.txt. LDUPers, Patrik - This draft addresses the IESG comments: - Responded to the IESG comment "It requires minimum mandatory-to-implement encryption, but fails to do same for integrity" by adding requirement S8 to deal with integrity. - Responded to the IESG comment "It needs a statement that avoidance of congestion and over-chattiness of the replication protocol must be considered in the design." by changing requirement G3 (to remove the text about network performance) and adding G11 (to specifically deal with chattiness). It also addresses some comments (I think they came from Kurt Zeilenga, Ed Reed, and Steven Legg) that came up on the mailing list since draft -10 and also fixes a typo or two that the authors found: - Modified the definition of "Sparse Replication" in Section 2. The original version was just wrong. - Replaced "privacy" with "confidentiality" in requirements S6 and S7. This seems to be the proper term in current usage. - Since the Access Control Model is still under discussion, the security considerations (Section 6) were changed to reference the Access Control Requirements which are already an RFC. This removes the only reference to an Internet Draft in the document. Section 7 (References) was changed accordingly. - Spelled out "Lightweight Directory Access Protocol" in Abstract. - Added "Unauthenticated Replication" as a synonym for Anonymous Replication in Section 2. - Added requirement MM8 ("MM8. Multi-master replication MUST support read-only replicas as well as read-write replicas."). The definition of multi-master replication in Section 2 covered this, but there were comments on the list that it should be an explicit requirement. - Changed a typo in Section B3 ("vendor's" -> "vendors'"). - Changed issue/expiration dates and draft number as needed. We did not address comments that would change WG consensus reached before the draft was submitted to the IESG. Rick Huber, for the authors --------------810D2087DFDB5DE1AA6D02DE Content-Type: text/x-vcard; charset=us-ascii; name="rvh.vcf" Content-Description: Card for Richard Huber Content-Disposition: attachment; filename="rvh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Huber;Richard tel;fax:+1 732-368-1690 tel;work:+1 732-420-2632 x-mozilla-html:FALSE org:AT&T Laboratories version:2.1 email;internet:rvh@att.com title:District Manager adr;quoted-printable:;;Room C3-3B30=0D=0A200 Laurel Avenue South;Middletown;New Jersey;07748;USA fn:Richard Huber end:vcard --------------810D2087DFDB5DE1AA6D02DE-- From owner-ietf-ldup@mail.imc.org Thu Feb 28 16:25:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20461 for ; Thu, 28 Feb 2002 16:25:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SLEB217793 for ietf-ldup-bks; Thu, 28 Feb 2002 13:14:11 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SLE9i17789 for ; Thu, 28 Feb 2002 13:14:09 -0800 (PST) Received: from qsun.mt.att.com ([135.16.30.2]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g1SLDAW14957; Thu, 28 Feb 2002 16:13:11 -0500 (EST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id QAA16018; Thu, 28 Feb 2002 16:13:09 -0500 Message-ID: <3C7E9D5A.51E3CBB1@att.com> Date: Thu, 28 Feb 2002 16:12:58 -0500 From: Richard Huber X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Internet Drafts Editor , " =?iso-8859-1?Q?F=E4ltstr=F6m?=, Patrik" , ietf-ldup@imc.org CC: Ellen Stokes , Russel Weiser , "Apple, Christopher" , "Strassner, John" , "Moats, Ryan" Subject: LDUP Requirements Content-Type: multipart/mixed; boundary="------------77514A3DB9445E2E85CA5410" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------77514A3DB9445E2E85CA5410 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK, let's try this again, this time with the draft actually attached! Internet Drafts Editor - Please publish the attached draft as draft-ietf-ldup-replica-req-11.txt. LDUPers, Patrik - This draft addresses the IESG comments: - Responded to the IESG comment "It requires minimum mandatory-to-implement encryption, but fails to do same for integrity" by adding requirement S8 to deal with integrity. - Responded to the IESG comment "It needs a statement that avoidance of congestion and over-chattiness of the replication protocol must be considered in the design." by changing requirement G3 (to remove the text about network performance) and adding G11 (to specifically deal with chattiness). It also addresses some comments (I think they came from Kurt Zeilenga, Ed Reed, and Steven Legg) that came up on the mailing list since draft -10 and also fixes a typo or two that the authors found: - Modified the definition of "Sparse Replication" in Section 2. The original version was just wrong. - Replaced "privacy" with "confidentiality" in requirements S6 and S7. This seems to be the proper term in current usage. - Since the Access Control Model is still under discussion, the security considerations (Section 6) were changed to reference the Access Control Requirements which are already an RFC. This removes the only reference to an Internet Draft in the document. Section 7 (References) was changed accordingly. - Spelled out "Lightweight Directory Access Protocol" in Abstract. - Added "Unauthenticated Replication" as a synonym for Anonymous Replication in Section 2. - Added requirement MM8 ("MM8. Multi-master replication MUST support read-only replicas as well as read-write replicas."). The definition of multi-master replication in Section 2 covered this, but there were comments on the list that it should be an explicit requirement. - Changed a typo in Section B3 ("vendor's" -> "vendors'"). - Changed issue/expiration dates and draft number as needed. We did not address comments that would change WG consensus reached before the draft was submitted to the IESG. Rick Huber, for the authors --------------77514A3DB9445E2E85CA5410 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ldup-replica-req-11.txt" Content-Disposition: inline; filename="draft-ietf-ldup-replica-req-11.txt" Content-Transfer-Encoding: 7bit Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: August 2002 Ryan D. Moats Lemur Networks Richard V. Huber AT&T Laboratories February 2002 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-11.txt 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/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) [RFC2251]. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. Stokes, et al Expires August 2002 [Page 1] Internet-Draft LDAPv3 Replication Requirements February 2002 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 [RFC2119]. Stokes, et al Expires August 2002 [Page 2] Internet-Draft LDAPv3 Replication Requirements February 2002 Table of Contents 1 Introduction.......................................................4 2 Terminology........................................................4 3 The Models.........................................................7 4 Requirements.......................................................8 4.1 General........................................................8 4.2 Model..........................................................9 4.3 Protocol......................................................10 4.4 Schema........................................................11 4.5 Single Master.................................................12 4.6 Multi-Master..................................................12 4.7 Administration and Management.................................12 4.8 Security......................................................13 5 Security Considerations...........................................14 6 Acknowledgements..................................................14 7 References........................................................14 A. APPENDIX A - Usage Scenarios....................................15 A.1. Extranet Example.............................................16 A.2. Consolidation Example........................................16 A.3. Replication Heterogeneous Deployment Example.................16 A.4. Shared Name Space Example....................................17 A.5. Supplier Initiated Replication...............................17 A.6. Consumer Initiated Replication...............................17 A.7. Prioritized attribute replication............................17 A.8. Bandwidth issues.............................................18 A.9. Interoperable Administration and Management..................18 A.10. Enterprise Directory Replication Mesh........................19 A.11. Failure of the Master in a Master-Slave Replicated Directory 19 A.12. Failure of a Directory Holding Critical Service Information..19 B. APPENDIX B - Rationale..........................................20 B.1. Meta-Data Implications.......................................20 B.2. Order of Transfer for Replicating Data.......................20 B.3. Schema Mismatches and Replication............................21 B.4. Detecting and Repairing Inconsistencies Among Replicas.......22 B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication........................................................23 B.6. Data Confidentiality and Data Integrity During Replication...26 B.7. Failover in Single-Master Systems............................27 B.8. Including Operational Attributes in Atomic Operations........28 Authors' Addresses..................................................28 Full Copyright Statement............................................29 Stokes, et al Expires August 2002 [Page 3] Internet-Draft LDAPv3 Replication Requirements February 2002 1 Introduction Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here. This document first introduces the terminology to be used, then presents the different replication models being considered. Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification. 2 Terminology The following terms are used in this document: Anonymous Replication - Replication where the endpoints are identified to each other but not authenticated. Also known as "unauthenticated replication". Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a replication base entry and includes all or some of the depending entries contained therein on a single server. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. This is a subset of the definition of a "replicated area" in X.525 [X.525]. Stokes, et al Expires August 2002 [Page 4] Internet-Draft LDAPv3 Replication Requirements February 2002 Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Atomicity Information - Information about atomic operations passed as part of replication. Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate. Fractional replication - The capability to filter a subset of attributes for replication. Incremental Update - An update that contains only those attributes or entries that have changed. Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica-group. Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Meta-Data - Data collected by the replication system that describes the status/state of replication. Multi-Master Replication - A replication model where entries can be written and updated on any of several master replica copies without requiring communication with other master replicas before the write or update is performed. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Stokes, et al Expires August 2002 [Page 5] Internet-Draft LDAPv3 Replication Requirements February 2002 Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both. Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier. Replica - An instance of an area of replication on a server. Replica-Group - The servers that hold instances of a particular area of replication. A server may be part of several replica-groups. Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered. Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts. Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica- group. Replication Base Entry - The distinguished name of the root vertex of a replicated area. Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time. Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle. Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single- and multi-master systems. Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of an area of replication. Topology - The shape of the directed graph describing the relationships between replicas. Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas. Stokes, et al Expires August 2002 [Page 6] Internet-Draft LDAPv3 Replication Requirements February 2002 Unauthenticated Replication - See Anonymous Replication. Update Propagation - Protocol-based process by which directory replicas are reconciled. 3 The Models The objective is to provide an interoperable, LDAP v3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments. There are five data consistency models. Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Consistency, Isolation, Durability) [ACID]. Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories (the X.500 model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX2]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas. Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. While model 1 may simplify support for atomicity in multi-master systems, the added complexity of the distributed 2-phase commit required for Model 1 is significant; Stokes, et al Expires August 2002 [Page 7] Internet-Draft LDAPv3 Replication Requirements February 2002 therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies. Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3. Interoperability among directories using LDAP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). In addition, the "core" specifications include numerous features which are not mandatory-to-implement (e.g. RECOMMENDED or OPTIONAL). There are also numerous elective extensions. Thus LDAP replication interoperability between independent implementations of LDAP which support different options may be limited. Use of applicability statements to improve interoperability in particular application spaces is RECOMMENDED. 4 Requirements 4.1 General G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. G3. LDAP replication SHOULD have minimal impact on system performance. G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate. G5. The LDAP replication standard SHOULD NOT limit the size of an area of replication or a replica. G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound. G7. All policy and state data pertaining to replication MUST be accessible via LDAP. G8. LDAP replication MUST be capable of replicating the following: Stokes, et al Expires August 2002 [Page 8] Internet-Draft LDAPv3 Replication Requirements February 2002 - all userApplication attribute types - all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFC 2251- 2256, 2829-2830) - attribute subtypes - attribute description options (e.g. ";binary" and Language Tags) G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions. Future standards track specifications SHOULD include a "Replication Considerations" section which indicates how and whether the new feature operates in a replicated environment. G10. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific. G11. The LDAP replication system should limit impact on the network by minimizing the number of messages and the amount of traffic sent. 4.2 Model M1. The model MUST support the following triggers for initiation of a replica cycle: a) A configurable set of scheduled times b) Periodically, with a configurable period between replica cycles c) A configurable maximum amount of time between replica cycles d) A configurable number of accumulated changes e) Change in the value of a critical OID f) As the result of an automatic rescheduling after a replication initiation conflict g) A manual request for immediate replication With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well- known place defined by the standard, e.g. the Replication Agreement(s). M2. The replication model MUST support both master-slave and multi- master relationships. M3. An attribute in an entry must eventually converge to the same set of values in every replica holding that entry. Stokes, et al Expires August 2002 [Page 9] Internet-Draft LDAPv3 Replication Requirements February 2002 M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, knowledge information, and name space information. M5. LDAP replication MUST NOT require that all copies of the replicated information be complete, but MAY require that at least one copy be complete. The model MUST support Partial Replicas. M6. The determination of which OIDs are critical MUST be configurable in the replication agreement. M7. The parameters of the replication process among the members of the replica-group, including access parameters, necessary authentication credentials, assurances of confidentiality (encryption), and area(s) of replication MUST be defined in a standard location (e.g. the replication agreements). M8. The replication agreements SHOULD accommodate multiple servers receiving the same area of replication under a single predefined agreement. M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet. M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition. M11. There MUST be a facility that can update, or totally refresh, a replica-group from a standard data format, such as LDIF format [RFC2849]. M12. An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received only once. 4.3 Protocol P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection (e.g. supplier cannot reach a replica). P2. LDUP replication SHOULD NOT send an update to a consumer if the consumer has previously acknowledged that update. Stokes, et al Expires August 2002 [Page 10] Internet-Draft LDAPv3 Replication Requirements February 2002 P3. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format. P4. Incremental replication MUST be allowed. P5. The replication protocol MUST allow either a master or slave replica to initiate the replication process. P6. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. In a multi-master environment this may lead to an unresolvable conflict. MM5 and MM6 discuss how to handle this situation. P7. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session. 4.4 Schema SC1. A standard way to determine what replicas are held on a server MUST be defined. SC2. A standard schema for representing replication agreements MUST be defined. SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined. SC4. A standard method for determining the location of replication agreements MUST be defined. SC5. A standard schema for publishing state information about a given replica MUST be defined. SC6. A standard method for determining the location of replica state information MUST be defined. SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT. SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP. SC9. An entry MUST be uniquely identifiable throughout its lifetime. Stokes, et al Expires August 2002 [Page 11] Internet-Draft LDAPv3 Replication Requirements February 2002 4.5 Single Master SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica. SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them. 4.6 Multi-Master MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication. MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles. MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. MM8. Multi-master replication MUST support read-only replicas as well as read-write replicas. 4.7 Administration and Management AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period. Stokes, et al Expires August 2002 [Page 12] Internet-Draft LDAPv3 Replication Requirements February 2002 AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. AM3. Access to replication agreements, topologies, and policy attributes MUST be provided through LDAP. AM4. The capability to check the differences between two replicas for the same information SHOULD be provided. AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided. AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. AM7. It MUST be possible to add a 'blank' replica to a replica-group, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system. AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-group. 4.8 Security The terms "data confidentiality" and "data integrity" are defined in the Internet Security Glossary [RFC2828]. S1. The protocol MUST support mutual authentication of the source and the replica directories during initialization of a replication session. S2. The protocol MUST support mutual verification of authorization of the source to send and the replica to receive replicated data during initialization of a replication session. S3. The protocol MUST also support the initialization of anonymous replication sessions. S4. The replication protocol MUST support transfer of data with data integrity and data confidentiality. S5. The replication protocol MUST support the ability during initialization of a replication session for an authenticated source and replica to mutually decide to disable data integrity and data confidentiality within the context of and for the duration of that particular replication session. Stokes, et al Expires August 2002 [Page 13] Internet-Draft LDAPv3 Replication Requirements February 2002 S6. To promote interoperability, there MUST be a mandatory-to- implement data confidentiality mechanism. S7. The transport for administrative access MUST permit assurance of the integrity and confidentiality of all data transferred. S8. To support data integrity, there must be a mandatory-to-implement data integrity mechanism. 5 Security Considerations This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security- related and general LDAP interoperability will be significantly impacted by the degree of consistency with which LDAP implementations support the access control requirements [RFC2820]. 6 Acknowledgements This document is based on input from IETF members interested in LDUP Replication. 7 References [ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317. [NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/h6tvg4z7.html, September, 2000. [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. Stokes, et al Expires August 2002 [Page 14] Internet-Draft LDAPv3 Replication Requirements February 2002 [RFC2254] T. Howes, "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [RFC2820] E. Stokes, D. Byrne, R. Blakley, P. Behera, "Access Control Requirements for LDAP", RFC 2820, May 2000. [RFC2828] R. Shirey, "Internet Security Glossary", RFC2828, May 2000. [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication Methods for LDAP", RFC 2829, May 2000. [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. [RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models. [X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, Information Technology - Open Systems Interconnection - The Directory: Replication. [XEROX] C. Hauser, "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] [XEROX2] Alan D. Demers, Mark Gealy, Daniel Greene, Carl Hauser, Wesley Irish, John Larson, Sue Manning, Scott Shenker, Howard Sturgis, Daniel Swinehart, Douglas Terry, Don Woods, "Epidemic Algorithms for Replicated Database Maintenance". Palo Alto, CA, Xerox PARC, January 1989. A. APPENDIX A - Usage Scenarios The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory Stokes, et al Expires August 2002 [Page 15] Internet-Draft LDAPv3 Replication Requirements February 2002 implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix. A.1. Extranet Example A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall. The requirements that follow from this scenario are: - One-way replication, single mastered. - Authentication of clients. - Common access control and access control identification. - Secure transmission of updates. - Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. A.2. Consolidation Example Company A acquires company B. Each company has an existing directory. During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model. Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schema. A.3. Replication Heterogeneous Deployment Example An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each. In this case, multi-master replication is required to ensure that the multiple replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements that follow from this scenario are: - Multi-Master replication - Common access control model and Access control model identification. Stokes, et al Expires August 2002 [Page 16] Internet-Draft LDAPv3 Replication Requirements February 2002 - Secure transmission of updates. - Replication among DITs with potentially differing schemas. A.4. Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model and Access control model identification. - Secure transmission of updates. A.5. Supplier Initiated Replication This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule. The requirements that follow from this scenario are: - Single-master environment. - Supplier-initiated replication. - Secure transmission of updates. A.6. Consumer Initiated Replication Again a single mastered replication topology, but the slave replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements that follow from this scenario are: - Single-master environment. - Consumer initiated replication. - Open scheduling (anytime). A.7. Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Stokes, et al Expires August 2002 [Page 17] Internet-Draft LDAPv3 Replication Requirements February 2002 Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states that passwords are critical and the new value must be available immediately (e.g. shortly) after any change. Replication needs to occur immediately for critical attributes/entries. The requirements that follow from this scenario are: - Incremental replication of changes. - Immediate replication on change of certain attributes. - Replicate based on time/attribute semantics. A.8. Bandwidth issues The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements that follow from this scenario are: - Minimize repetitive updates when replicating from multiple replication paths. - Incremental replication of changes. - Provide replication cycles to delay and/or retry when connections cannot be reached. - Allowances for consumer initiated or supplier initiated replication. A.9. Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP'RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements that follow from this scenario are: - Provides replication audit history. - Provisions for managing conflict resolution. - Provide LDAP access to predetermined agreements, topology and policy attributes. Stokes, et al Expires August 2002 [Page 18] Internet-Draft LDAPv3 Replication Requirements February 2002 - Provide operations for comparing replica's content for validity. - Provide LDAP access to status and audit information. A.10. Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers' replication. The requirements that follow from this scenario are: - One predefined replication agreement that manages a single area of replication that is held on numerous servers. - Common support of replication management knowledge across vendor implementation. - Rescheduling and continuation of a replication cycle when one server in a replica-group is busy and/or unavailable. A.11. Failure of the Master in a Master-Slave Replicated Directory A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered. The requirements that follow from this scenario are: - An existing slave replica must be "promote-able" to become the new master. - The "promotion" must be done without significant downtime, since updates to the directory will continue. A.12. Failure of a Directory Holding Critical Service Information An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted. Stokes, et al Expires August 2002 [Page 19] Internet-Draft LDAPv3 Replication Requirements February 2002 The requirements that follow from this scenario are: - Multi-master replication - Ability to reschedule replication sessions - Support for manual review and override of replication conflict resolution B. APPENDIX B - Rationale This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements. B.1. Meta-Data Implications Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta- data from the system while still ensuring that meta-data will not grow forever. B.2. Order of Transfer for Replicating Data Situations may arise where it would be beneficial to replicate data out-of-order (e.g. send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single- master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory. While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise. As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that Stokes, et al Expires August 2002 [Page 20] Internet-Draft LDAPv3 Replication Requirements February 2002 some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted attribute so that the schema change can be done with no problems. If the schema change moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined. In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi- master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out- of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication. Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7. B.3. Schema Mismatches and Replication Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendors' products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3. There are only a few possible responses when a mismatch is discovered. - Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10. - Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the implementation; in the extreme it could support use of the replication protocol in meta-directories. - Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer. Requirement M10 is intended to exclude the last option. Stokes, et al Expires August 2002 [Page 21] Internet-Draft LDAPv3 Replication Requirements February 2002 Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches. Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead. The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided. One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas. For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include: - All schema elements are replicated. - Schema elements are replicated only if they are used by attributes that are being replicated. - Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol. B.4. Detecting and Repairing Inconsistencies Among Replicas Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies. A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same replication base entry and compare the answers, possibly by BINDing to each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g. chaining), mechanisms to force access to a particular replica should be supplied. Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server Stokes, et al Expires August 2002 [Page 22] Internet-Draft LDAPv3 Replication Requirements February 2002 it has a replication agreement with and report the differences back to the client as the result If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be. When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication. Requirements AM2, AM4, and AM5 address these needs. B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied. As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled. While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration. In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that the change to A takes precedence using whatever rules are in force for conflict resolution. B.5.1. Create-Create A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B. Stokes, et al Expires August 2002 [Page 23] Internet-Draft LDAPv3 Replication Requirements February 2002 In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed. In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.) As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B. The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica-group (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed. In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired. B.5.2. Rename-Rename On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN. In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists. In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values. Stokes, et al Expires August 2002 [Page 24] Internet-Draft LDAPv3 Replication Requirements February 2002 Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5. B.5.3. Locking Based on Atomicity of ModifyRequest There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated. B.5.4. General Principles With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server. To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening Stokes, et al Expires August 2002 [Page 25] Internet-Draft LDAPv3 Replication Requirements February 2002 operations by another user may have changed the value. In the multi- master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above. The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment. B.5.5. Avoiding the Problem The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: - Several directory users/applications are changing the same data. - They are changing the data before previous changes have replicated. - They are using different directory servers to make these changes. - They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request. If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. B.6. Data Confidentiality and Data Integrity During Replication Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected against intercept or modification during replication. In some cases, the network environment (e.g. a private network) may provide sufficient data confidentiality and integrity for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data confidentiality and Stokes, et al Expires August 2002 [Page 26] Internet-Draft LDAPv3 Replication Requirements February 2002 integrity were not made requirements for all replication sessions. But there are a substantial number of applications that will need data confidentiality and integrity for replication, so there is a requirement (S4) that the protocol allow for data confidentiality and integrity in those cases where they are needed. Typically, the policy on the use of confidentiality and integrity measures would be held in the replication agreement per requirement M7. This leaves the question of what mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data confidentiality and integrity mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S6) for mandatory-to-implement data confidentiality and integrity mechanisms. Anonymous replication (requirement S3) is supported since it may be useful in the same sorts of situations where data integrity and data confidentiality protection are not needed. B.7. Failover in Single-Master Systems In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system. One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole. Factors that designers and implementors should consider when working on failover include: - If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set. Stokes, et al Expires August 2002 [Page 27] Internet-Draft LDAPv3 Replication Requirements February 2002 - If data privacy mechanisms (e.g. encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas. - It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications. - The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated. - The old master will eventually be repaired and returned to the replica-group. It might join the group as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed. - Availability would be maximized if the whole failover process could be automated (e.g. failover is initiated by an external system when it determines that the original master is not functioning properly). B.8. Including Operational Attributes in Atomic Operations LDAPv3 [RFC2251] declares that some operations are atomic (e.g. all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data. It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place. Authors' Addresses Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, Utah 84106 USA E-mail: rweiser@trustdst.com Stokes, et al Expires August 2002 [Page 28] Internet-Draft LDAPv3 Replication Requirements February 2002 Telephone: +1 801 326 5421 Fax: +1 801 326 5421 Ellen J. Stokes Tivoli Systems 9442 Capital of Texas Hwy N Austin, TX 78759 USA E-mail: estokes@tivoli.com Telephone: +1 512 436 9098 Fax: +1 512 436 1190 Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@lemurnetworks.net Telephone: +1 402 894 9456 Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Stokes, et al Expires August 2002 [Page 29] Internet-Draft LDAPv3 Replication Requirements February 2002 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stokes, et al Expires August 2002 [Page 30] --------------77514A3DB9445E2E85CA5410-- From owner-ietf-ldup@mail.imc.org Thu Feb 28 20:57:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29005 for ; Thu, 28 Feb 2002 20:57:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g211jBH24075 for ietf-ldup-bks; Thu, 28 Feb 2002 17:45:11 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-155.rochester.rr.com [24.169.98.155]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g211hoi23977 for ; Thu, 28 Feb 2002 17:43:50 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Thu, 28 Feb 2002 20:40:57 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 28 Feb 2002 20:40:51 -0700 From: "Ed Reed" To: , Cc: , , , Subject: Re: Question re: requirement S3 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g211hpi23979 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yeah, okay - I can live with the ftp example, and I do keep forgetting about how running things behind a datacenter firewall (even on a blade server cluster, for that matter) could benefit from such a thing. I'll relent. I disagree, though, that it should be considered useful when setting up a new replica...but then again, I've got nothing against requiring a DSA to go off-server to get authentication credentials/certificates for authenttication, and I know not everyone does... Sigh - I will point out that Anonymous FTP has been a royal pain in the administration of may sites - not only because it's a denial of service attack waiting to happen (if your firewalls slip), but because of the "innovative" ways of using it (IRC) that plague unspecting administrators. Ready for LDUP to fill the same role? Ed >>> Richard Huber 02/28/02 10:41AM >>> This is my recollection of some of the discussion we had among the authors when we added S3. The other authors can chip in if they remember things differently. First, S3 is not intended to require that servers always accept anonymous replication requests. It just says that the protocol needs to support such requests if a given pair of servers is configured to use them. An analogous situation is FTP, where anonymous FTP is supported in the protocol but is turned of on many FTP servers. So when you say "of course, there's nothing to prevent someone from trying to initiate one" it seems that we may already be in agreement. As for the circumstances where it might be useful to have anonymous replication, a set of replicating directory servers on a private net behind a firewall that only lets through LDAP requests would not need authentication among the replicating servers; security in this case has been provided by means outside of LDAP/LDUP. These are the same sorts of situations where the confidentiality features might not be needed. And there may be some situations in setting up a new replica where it is useful to have anonymous replication (see Section 5.1 and 5.1.1 of the MRM draft). There are certainly many situations where anonymous replication is a very BAD idea. It should be disabled in such situations. But it should not be absolutely forbidden in all situations. Rick Huber Ed Reed wrote: > Uppili and I are working on updating the Architecture document (!) and have a question about requirement S3 - The protocol MUST also support the initialization of anonymous replication sessions. > > Politely, are you sure? We would much rather strictly prohibit acceptance of LDUP replication sessions over unauthenticated anonymous connections. (of course, there's nothing to prevent someone from trying to initiate one, I suppose, but there certainly ought not be any requirement to accept one). > > Why is there any reason for any server to ever accept anonymous assertion of replica changes it is supposed to send or receive? > > Your clarification will be greatly appreciated. In the meantime, the architecture document will continue to require authentication for all replication sessions. > > Ed and Uppili > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 585 624 2402 > http://www.Reed-Matthews.COM > Note: Area code is 585 From owner-ietf-ldup@mail.imc.org Thu Feb 28 21:45:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00865 for ; Thu, 28 Feb 2002 21:45:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g212bIt25709 for ietf-ldup-bks; Thu, 28 Feb 2002 18:37:18 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g212bGi25705 for ; Thu, 28 Feb 2002 18:37:16 -0800 (PST) Received: (qmail 1197 invoked from network); 1 Mar 2002 02:37:51 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 1 Mar 2002 02:37:51 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: , Subject: RE: Basic Access Control for LDAP Date: Fri, 1 Mar 2002 13:36:13 +1100 Message-ID: <006701c1c0c9$dbaeccb0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > Actually, my question is a bit more basic - > > Does allUsers include entries of any and all object classes, or only > object classes derived from "person", or only "person"s with, say, > a password attribute present, or some other definition? As far as Basic Access Control is concerned, an identified user (i.e. a requestor) is just a distinguished name. The distinguished name doesn't even have to refer to a real entry, so the object class of the user's entry, if such an entry exists, is completely irrelevant. The allUsers case includes not only any identified user, but also completely anonymous requestors for which no associated distinguished name was able to be established at bind time. Regards, Steven > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 585 624 2402 > http://www.Reed-Matthews.COM > Note: Area code is 585 > > >>> "Steven Legg" 02/28/02 01:16AM >>> > > Ed, > > Ed Reed wrote: > > One question from reading the drafts (for now) - > > > > What constitutes a "user" for the purpose of ACI UserClasses > > value allUsers? > > In the first instance it is anyone/anything who manages to bind in, > regardless of their authorization identity, but it is qualified by > the AuthenticationLevel and whether a permission is being granted > or denied. > > For a permission being granted: > > 1) If the AuthenticationLevel is "none" then allUsers > includes everyone, > regardless of authorization identity, anonymous included. > > 2) If the AuthenticationLevel is "simple" then allUsers includes all > users who have authenticated with at least a user name and password. > Anonymous users and users who have not been authenticated are > excluded. > > 3) If the AuthenticationLevel is "strong" then allUsers includes all > users who have authenticated with strong credentials, e.g digital > signatures. Anonymous users, unauthenticated users and password > authenticated users are excluded. > > For a permission being denied, allUsers includes everyone, > regardless of authorization identity and authentication level. > > Regards, > Steven > > >