[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed LDUP Charter
Alan,
It certainly would make life easier for people with large X.500 installations.
Perhaps a subset of DISP could be defined to allow developers to get
started implementing replication? As it currently stands, users will
either have to install a large X.500, that may not otherwise be warrented
in a smaller organization, or they will have to put up with proprietary
shadowing methods.
Either way LDAP v3 is effectively neutered. Large organizations are simply
not going to install it without a good distribution capability. It gets
even worse when you are trying to implement a PKI infrastructure which
needs to interoperate with customers, partners and vendors.
I would suggest pushing forward with a subset of DISP is the best way
forward. The protocols and information model have already been developed.
They just need to be molded slightly for our purposes. We can then add
multi-master replication later, if people are still keen on that.
Cheers, ....Erik.
-------------------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP/X.500 Consulting and Training
http://wwww.geotrain.com
+1 (604) 244-9131
At 13:22 24/09/98 +1000, Alan Lloyd wrote:
>Chris
>edits - there are a few "Jan 1998s" in the task list
>
>
>I would not mind an honest answer re this lists view on the integration
>or harmonisation of X.500 DISP. It seems LDAP is almost at DAP
>capability (with the few additions I have proposed). However with LDAP
>the world has now got a few issues to say the least re scaling and the
>operational management overheads of it.
>
>ie. There still no firm system design on how clients find and select
>master or replicas - without masses of configuration by hand.
>
>So candid views are welcomed.
>
>regards alan
>
>PS Lightweight Directory Access Protocol Replication Information
>Transport Protocol - is a bit long.
>
>
>----------
>From: capple@xxxxxxxxxxxxxxxxxxxxxx
>To: ietf-ldup@xxxxxxx
>Sent: 9/24/98 6:03:32 AM
>Subject: Proposed LDUP Charter
>
>This is the version of the charter that John Strassner and I
>plan to send to the Apps Co-ADs for IESG review to form a WG.
>Please post comments to the list by 10/1/1998. On 10/2/1998
>this will be sent to the Co-ADs unless there are changes which
>require more discussion on the list.
>
>Thanks!
>
>Chris Apple
>John Strassner
>
>LDAPv3 Duplication/Replication/Update Protocol (LDUP) Charter
>
>Chair(s):
> Chris Apple <capple@xxxxxxx>
> John Strassner <johns@xxxxxxxxx>
>
>Applications Area Director(s):
>
> Keith Moore <moore@xxxxxxxxxx>
> Patrik Faltstrom <paf@xxxxxxxx>
>
>Operations and Management Area Advisor:
>
> Patrik Faltstrom <paf@xxxxxxxx>
>
>Mailing lists:
> General Discussion: ietf-ldup@xxxxxxx
> To Subscribe: ietf-ldup-request@xxxxxxx
> In Body: subscribe
> Archive: http://www.imc.org/ietf-ldup/
>
>Description of Working Group:
>
>As LDAPv3 becomes more widely deployed, replication of data across
>servers running different implementations becomes an important
>part of providing a distributed directory service. However, the LDAPv3
>community, to date, has focused on standardizing the client-server
>access protocol. Therefore, this group will standardize master-slave
>and multi-master LDAPv3 replication as defined below:
>
> Multi-Master Replication - A replication model where entries can
> be written and updated on any of several replica copies, without
> requiring communication with other masters before the write or
> update is performed.
>
> Master-Slave, or Single-Master Replication - A replication model
> that assumes only one server, the master, allows write access to
> the replicated data. Note that Master-Slave replication can be
> considered a proper subset of multi-master replication.
>
>Our approach is to first develop a set of requirements for LDAPv3
>directory replication and write an applicability statement defining
>scenarios on which replication requirements are based. An engineering
>team was formed consisting of different vendors and the co-chairs in
>order to harmonize the existing approaches into a single standard
>approach. All of these have been accomplished during the pre-working
>group stage. It should be noted, however, that replication using
>heterogeneous servers is dependent on resolving access control issues,
>which are the domain of other working groups.
>
>The new replication architecture support all forms of replication
>mentioned above. Six areas of working group focus have been identified
>through LDUP Engineering Team discussions, each leading to one or
>more documents to be published:
>
> * Abstract Model of LDAPv3 Replication
>
> This documents a general-purpose LDAPv3 replication
> architecture, define key components of this architecture,
> describes how these key components functionally behave,
> and describes how these components interact with each other
> when in various modes of operation
>
> * LDAPv3 Replication Information Model
>
> Defines the schema and semantics of information used to
> operate, administer, maintain, and provision replication
> between LDAPv3 servers. Specifically, this document will
> contain common schema specifications intended to
> facilitate interoperable implementations with respect to:
>
> + replication agreements
> + consistency models
> + replication topologies
> + managing deleted objects and their states
> + administration and management
>
> * LDAPv3 Replication Information Transport Protocol
>
> LDAPv3 extended operation and control specifications
> required to allow LDAPv3 to be used as the transport
> protocol for information being replicated
>
> * Mandatory Replica Management
>
> Specifications required to allow administration,
> maintenance, and provisioning of replicas and
> replication agreements. These specifications may
> take the form of definitions for LDAPv3 extended
> operations, controls, and/or new schema elements.
>
> * Conflict Detection and Resolution Procedures
>
> Procedures for detection and resolution of conflicts
> between the state of multiple replicas that contain
> information from the same unit of replication.
>
> * Profiles
>
> Including the Abstract Replication Model, Information
> Model, LDAPv3 Protocol Extensions, and Conflict Detection
> and Resolution Procedures for:
>
> + Master-Slave LDAPv3 Directory Replication
> + Multi-Master LDAPv3 Directory Replication
>
>Milestones:
>
>done May 1998 LDAPv3 Directory Replication Requirements and
> Applicability Statement I-D Published.
>
>done May 1998 Participants publish LDAPv3 replication concept
> proposals to LDUP Engineering team mailing list.
>
>done Jun 1998 Harmonization of different vendor replication
> LDAPv3 concept proposals is complete.
>
> Sep 1998 LDAPv3 Abstract Model of Replication (based on the
> concensus of the LDUP Engineering Team) is published
> as an I-D.
>
> Oct 1998 LDAPv3 Directory Replication Requirements and
> Applicability Statement I-D goes to WG Last Call
> as Informational.
>
> Oct 1998 LDAPv3 Replication Information Model is published
> as an I-D.
>
> Oct 1998 LDAPv3 Replication Information Transport Protocol is
> published as an I-D.
>
> Nov 1998 LDAPv3 Mandatory Replica Management is published as
> an I-D.
>
> Nov 1998 LDAPv3 Conflict Detection and Resolution Procedures
> is published as an I-D.
>
> Dec 1998 LDAPv3 Abstract Model of Replication goes to WG Last
> Call as Informational.
>
> Dec 1998 LDAPv3 Multi-Master Replication Profile is published
> as an I-D.
>
> Jan 1998 LDAPv3 Master-Slave Replication Profile is published
> as an I-D.
>
> Jan 1998 LDAPv3 Replication Information Model goes to WG Last
> Call as Proposed Standard.
>
> Jan 1998 LDAPv3 Replication Information Transport Protocol
> goes to WG Last Call as Proposed Standard.
>
> Feb 1999 LDAPv3 Mandatory Replica Management goes to WG Last Call
> as Proposed Standard.
>
> Feb 1999 LDAPv3 Conflict Detection and Resolution Procedures goes
>to
> WG Last Call as Proposed Standard.
>
> Apr 1999 LDAPv3 Master-Slave LDAPv3 Replication Profile goes to
>WG
> Last Call as Proposed Standard.
>
> Apr 1999 LDAPv3 Multi-Master LDAPv3 Replication Profile goes to
>WG
> Last Call as Proposed Standard.
>
>
>