RE: LDUP WG Charter

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

 Chris - in line with my usual style of response one should not confuse
the word "Distributed" with replicated. They are quite different in
directory operations. This replication work is of importance to the LDAP
server community who have to replicate everything to everywhere just to
do authentication of users to many servers.
Mind you the issue of cert path processing is still impossible in this
case.... :-(((

As you know I think like most out here that replicate everything to
everywhere approach is operationally broken.

As most are now saying now, LDAP is Hand-draulic ie what it does not do
- namely distribution and mutual authentication then humans have to with
LDIF, manual work and massess of replica utilities AND the bigger the
system gets the worse it becomes.

Never the less some will require this but pehaps the urgency is to look
at scale.
On the other hand - one can see that most directory oriented companies
are realising that LDAP servers dont do much for "distributed" services
and their users and are going down then X.500 path which you know
already replicates quite well.

 I think the issue that should be addressed by LDAP servers suppliers is
that this will put them even further back behind X.500 distributed
systems.

In addition one only has to say with 10 ldap servers and 10 replicas to
be managed to everywhere one needs a few more staff - and thats enough
to put people off.


But thats a choice eh?
regards alan

----------
From: capple@xxxxxxxxxxxxxxxxxxxxxx
To: ietf-ldup@xxxxxxx
Cc: johns@xxxxxxxxx; capple@xxxxxxxxxxxxxxx; paf@xxxxxxxx
Sent: 7/26/98 11:02:55 AM
Subject: LDUP WG Charter

The charter John Strassner and I would like to send up for IESG review
follows. We'd like to limit the comment period to two (2) calendar
weeks.
This period starts now, 7/25/1998, and ends on 8/11/1998.

Please post comments on the list.

After the comment period, we will incorporate changes as concensus
indicates and send to the Apps Co-ADs with a request for IESG review
and approval to create the LDUP WG.

John Strassner
Chris Apple

IETF LDUP Proposed WG Co-Chairs

Charter

LDAP Duplication/Replication/Update Protocol(ldup)

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 LDAP becomes more widely deployed, replication of data across
servers running different implementations becomes an important
part of providing a distributed directory service. However, the LDAP
community, to date, has focused on standardizing the client-server
access protocol. Therefore, this group will standardize master-slave
and multi-master LDAP 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 LDAP
directory replication and write an applicability statement defining
scenarios on which replication requirements are based. Once the
requirements and applicability statement have been drafted, the
working group will harmonize vendor/vendor-team replication concept
proposals; such concept proposals will be constructed in such a manner
as to support all forms of replication mentioned above. Each proposal
will include provisions allowing functional decomposition of
multi-master
replication into a proper subset required to implement master-slave
replication. After vendor replication concept proposals have been
harmonized, a single replication architecture document will be
published.

Six areas of working group focus have been identified through 
LDUP Engineering Team discussions:

	* Abstract Model of LDAP Replication

	  This would document a general-purpose LDAP replication
	  architecture, define key components of this architecture,
	  describe how these key components functionally behave,
	  and describe how these components interact with each other
	  when in various modes of operation)

	* LDAP Replication Information Model

	  Schema and semantics of information used to operate,
	  administer, maintain, and provision replication between
	  LDAP servers. Specifically, this document will contain
	  common schema specifications intended to facilitate
	  interoperable implementations with respect to:

		+ replication agreements
		+ consistency models
		+ replication topologies
		+ graveyards, tombstones, and zombies
		+ administration and management

	* LDAP Replication Information Transport Protocol

	  LDAP extended operation and control specifications
	  required to allow LDAP 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 LDAP 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, LDAP Protocol Extensions, and Conflict Detection
	  and Resolution Procedures for:

		+ Master-Slave LDAP Directory Replication
		+ Multi-Master LDAP Directory Replication

Milestones:

May 1998  Directory Replication Requirements and Applicability
	  Statement I-D Published.

May 1998  Vendors publish replication concept proposals to
	  LDUP Engineering team mailing list.

Jun 1998  Harmonization of vendor replication concept proposals
	  is complete.

Aug 1998  Directory Replication Requirements and Applicability
	  Statement I-D goes to WG Last Call as Informational.

Aug 1998  Abstract Model of LDAP Replication (based on the
	  concensus of the LDUP Engineering Team) is published
	  as an I-D.

Sep 1998  LDAP Replication Information Model is published as an I-D.

Sep 1998  LDAP Replication Information Transport Protocol is
	  published as an I-D.

Oct 1998  Abstract Model of LDAP Replication goes to WG Last Call
	  as Informational.

Oct 1998  Mandatory LDAP Replica Management is published as an I-D.

Oct 1998  Conflict Detection and Resolution Procedures is
	  published as an I-D.

Nov 1998  LDAP Replication Information Model goes to WG Last Call as
	  Proposed Standard.

Nov 1998  LDAP Replication Information Transport Protocol goes to
	  WG Last Call as Proposed Standard.

Dec 1998  Master-Slave LDAP Replication Profile is published
	  as an I-D.

Dec 1998  Multi-Master LDAP Replication Profile is published
	  as an I-D.

Jan 1999  Mandatory LDAP Replica Management goes to WG Last Call
	  as Proposed Standard.

Jan 1999  Conflict Detection and Resolution Procedures goes to
	  WG Last Call as Proposed Standard.

Mar 1999  Master-Slave LDAP Replication Profile goes to WG Last Call
	  as Proposed Standard.

Mar 1999  Multi-Master LDAP Replication Profile goes to WG Last Call
	  as Proposed Standard.