Subject: Revised WG Charter Proposal

From: Christopher Apple <[email-masked]>
Date: Mon, 5 Nov 2001 15:30:56 -0500

Based on input from document editors and a little editing from me,
please review the following. The open review period of this begins
today, Monday, November 5, 2001 and will last for 7 days.

The review period therefore ends on Monday, November 12, 2001.

Silence equals consent. This will be sent to the ADs for review
subject to incorporation of comments sent, discussed, and
vetted on the WG mailing list shortly after November 12, 2001.

LDAP Duplication/Replication/Update Protocols (ldup) 

Last Modified: 05-Nov-01 

Chair(s):

Chris Apple <[email-masked]>
John Strassner <[email-masked]>

Applications Area Director(s): 

Ned Freed <[email-masked]>
Patrik Faltstrom <[email-masked]>

Applications Area Advisor: 

Patrik Faltstrom <[email-masked]>

Mailing Lists:
 
General Discussion:[email-masked] 
To Subscribe: [email-masked] 
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: 

o 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. 

o 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. 

The WG's 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. Should these issues not be resolved outside of
the LDUP WG in a timely manner relative to the WG's needs, the
WG will be re-chartered subject to Applications AD/IESG approval
to include the minimum required work.

The new replication architecture support all forms of replication
mentioned above. Seven areas of working group focus have been
identified through LDUP Engineering Team discussions, each leading
to one or more Engineering Team discussions, each leading to one
or more documents to be published: 

o LDAPv3 Replication Architecture 

   This documents a general-purpose LDAPv3 replication architecture,
   defines 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. 

o 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 

o 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 

o LDAPv3 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. 

o LDAPv3 Update Reconciliation Procedures 

   Procedures for detection and resolution of conflicts between the
   state of multiple replicas that contain information from the same
   unit of replication. 

o LDAPv3 Replication Usage Profile 

   Including the LDAPv3 Replication Architecture, Information Model,
   Protocol Extensions, and Update Reconciliation Procedures for: 

      + LDAPv3 Master-Slave Directory Replication 

      + LDAPv3 Multi-Master Directory Replication 

o LDAPv3 Client Update 

   A protocol that enables an LDAP client to synchronize with the
   content of a directory information tree (DIT) stored by an LDAP
   server and to be notified about the changes to that content. 

The work being done in the LDUP WG should be coordinated to the
closest extent possible with similar work being done in the ITU.
This is necessary both because LDAP depends on X.500 and because
it makes sense from an operational perspective. 

Goals and Milestones:

Done    Submit I-D on LDAPv3 Directory Replication Requirements. 

Done    Submit Internet-Draft on LDAPv3 Replication Information Model. 

Done    Submit I-D on LDAPv3 Update Reconciliation Procedures. 

Done    Revise I-D on LDAPv3 Directory Replication Requirements. 

Done    Revise I-D on LDAPv3 Replication Architecture. 

Done    Revise I-D on LDAPv3 Replication Architecture. 

Done    Revise I-D on LDAPv3 Replication Information Model. 

Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.

Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last
Call as Informational.

Done    Submit I-D on LDAPv3 Mandatory Replica Management.

Done	Submit I-D on General LDUP Usage Profile.

Done	Submit I-D on LDAPv3 Operations Framing.

Oct 01	I-D on LDAPv3 Extended Operations for Framing goes to WG Last
Call as Proposed Standard.

Nov 01	Submit I-D on LDAPv3 Replication Information Transport Protocol.

Nov 01	Revise I-D on General LDUP Usage Profile.

Nov 01	Revise I-D on LDAPv3 Mandatory Replica Management.

Dec 01	LDAPv3 Client Update Protocol I-D goes to WG Last Call as
Proposed Standard. 

Feb 02	LDAPv3 Replication Architecture I-D goes to WG Last Call as
Informational. 

Mar 02	LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call
as Proposed Standard.

Mar 02	LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
Proposed Standard. 

Mar 02	LDAPv3 Replication Information Model I-D goes to WG Last Call as
Proposed Standard.

Mar 02	LDAPv3 Replication Information Transport Protocol I-D goes to WG
Last Call as Proposed Standard.

Mar 02	Re-evaluate Charter and Milestones.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email-masked]> 
(V) +1 610 425 2860

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 06 Nov 2001 19:04:21 -0800

I am convinced the WG will need to extend the X.500 models
in order to deliver a multi-master replication specification
which meets the WG requirements.  This activity does not
appear to be presently within scope of the current or proposed
charter.  As the issue of whether this work is within scope or
not has come up previously, I believe the charter should be
clarified in this area.

If the consensus is this work is within scope, I suggest:

  This WG will deliver a technical specification updates the
  X.500 models used by LDAP to support multi-master replication
  yet maintain consistency with the existing models when
  restricted to single-master replication.

otherwise I suggest:
  This WG will deliver specifications which extend, but do
  not update or replace, the X.500 models used by LDAP.

Note that I believe that this work is not within scope and
should remain so and hence recommend the latter clarification.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 07 Nov 2001 21:24:54 -0800

I suggest striking all the "REVISE" milestones... and
replacing all "WG Last Call" milestones with "Recommend
to the IESG for consideration as a ...".   From past
experience, each document has multiple WG Last Calls...
it's successfully completely the WG Last Call and
progressing the I-D that counts.

And I suggest the last milestone be:
        Revise charter or conclude
as "Re-evaluate Charter and Milestones" doesn't sound like
much of a commitment to successfully conclude.

---

From: "John Strassner" <[email-masked]>
Date: Thu, 8 Nov 2001 09:09:53 -0700

Kurt,

there are many different WGs that use "REVISE" as well as many different
WGs that use "WG Last Call". Furthermore, this wording is consistent with
current practice.

I do agree with your suggested change to the last milestone.

regards,
John

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Wednesday, November 07, 2001 10:25 PM
To: Christopher Apple
Cc: [email-masked]'; John Strassner (E-mail)
Subject: Re: Revised WG Charter Proposal