Subject: Revised WG Charter Proposal

From: "Chris Apple" <[email-masked]>
Date: Tue, 18 Mar 2003 06:52:37 -0500

LDAP Duplication/Replication/Update Protocols (ldup)

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. 

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 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 Profiles 

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

	+ LDAPv3 Replication General Usage

	+ LDAPv3 Single-Master 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 I-D 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 Information Model.  
Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.  
Done    Revise I-D on LDAPv3 Replication Architecture.  
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 LDAPv3 Replication General Usage Profile.
MAY 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
MAY 03  Revise LDAPv3 Replication Information Model I-D.  
MAY 03  Revise LDAPv3 Replication Architecture I-D.  
MAY 03  Revise LDAPv3 Client Update Protocol I-D. 
MAY 03  Revise LDAPv3 Replication Information Transport Protocol I-D.  
MAY 03  LDAPv3 Extended Operations for Framing I-D goes to WG Last Call as
Proposed Standard.  
MAY 03  Revise LDAPv3 Mandatory Replica Management I-D.  
JUN 03  Revise LDAPv3 Replication General Usage Profile I-D.
JUN 03  Submit I-D on LDAPv3 Single-Master Directory Replication Profile.
JUN 03  Submit I-D on LDAPv3 Multi-Master Directory Replication Profile.
JUN 03  Poll the mailing list to request that issues be raised on all I-Ds.
JUL 03  Revise any I-Ds as required according to consensus of issue
resolution on the mailing list.
AUG 03  Consider which documents are ready for WG Last Call and establish
sequencing.
SEP 03  Reevaluate Charter and Milestones

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com

---

From: [email-masked] (Mark C Smith)
Date: Tue, 18 Mar 2003 09:16:43 -0500

> MAY 03  Revise LDAPv3 Client Update Protocol I-D.

Since LCUP has already been through one WG last call, I would expect it 
to be ready for another one, followed by submission to the IESG in the 
May or June 2003 timeframe. LCUP has no dependencies on the core LDUP 
replication documents.

> SEP 03  Reevaluate Charter and Milestones

Are the area directors going to be happy with this? I don't see any date 
on the proposed charter for when a document leaves the working group, 
which seems strange to me.

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.

---

From: "Chris Apple" <[email-masked]>
Date: Tue, 18 Mar 2003 19:49:00 -0500

It was my intent to be fuzzy about the end game milestones.

This milestone is where documents would leave the WG (after they
pass through a last call successfully).

sequencing.

You are correct about the additional WG Last Call for LCUP. An error that I
will correct with the next revision of the WG Charter Proposal.

My intent behind the SEP 03 milestone is that it's a drop dead date.

If all of the documents are not at least ready to enter WG Last Call by this
date, we will have missed the schedule by too much to justify continuing and
"the
plug will be pulled." I expect that we will have a number of documents that
have
Actually passed WG Last Call before then. However, given the WG's history, I
think
its prudent to have a drop dead date in mind.

We may change the wording of the milestone so that this intent is more
clear.

DSI Consulting, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark C Smith
Sent: Tuesday, March 18, 2003 9:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Revised WG Charter Proposal

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 27 Mar 2003 10:54:24 -0800

At this point, "revising" and "WG last call" milestones seem
quite pointless and meaningless to me (because they can be
declared "Done" without actually making any forward progress).

We need "we think we're done" milestones.  I strongly suggest
that for each I-D we include a milestone of the form:

DATE	Progress FOO I-D to the IESG for consideration as a
	BAR RFC

where DATE is the date which this WG commits to completing
its work on the I-D (excepting post-IESG-progression work),
FOO is the name of the I-D, and BAR is indicative of the
track which the I-D is to be considered for.

Kurt