RE: WG Charter Proposal v2

As a reminder:

These issues need to be resolve on the mailing list *before*
the April 7th commenting deadline elapses.

To-Be-Resolved:

Issue 1:

Keep multi-master and single-master replication profiles
as deliverables? Or remove them.

Issue 2:

Mandatory (?) Replica Management document title is
now somewhat misleading. Perhaps we should change it to
*Recommended* Replica Management?

John and I are choosing to foster resolution of this
issue by changing the way that the issue was raised.

If John and I do not see a significant number of postings
to the working group mailing list objecting to the document
title change, we will declare consensus that we should
change the document title, the document editors will make
that change with the next revision of the document, and
the document title will be changed in the proposed WG
charter revision prior to reposting on April 8th.

Issue 1 may require a bit of discussion to resolve.

Failure to resolve Issue 1 through mailing list discussion
by April 7th *could* mean that John and I will be forced to
declare that the LDUP WG should not continue its work due
to a lack of interest in revising the WG charter.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email protected]

http://www.dsi-consulting.com

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Chris Apple
Sent: Thursday, March 20, 2003 5:14 PM
To: [email protected]; [email protected]
Cc: 'John Strassner'
Subject: RE: WG Charter Proposal v2



Thanks to Tim Hahn for bringing to my attention that I meant to use
April 7, 8, and 15 for the dates below rather than the same days in
March.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email protected]

http://www.dsi-consulting.com

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Chris Apple
Sent: Thursday, March 20, 2003 6:46 AM
To: [email protected]
Cc: John Strassner
Subject: WG Charter Proposal v2



Changes in this version:

Incorporated comments made during the WG meeting session.

Incorporated comments from mailing list.

Mostly, these changes related to changing the
working group description text to incorporate
established consensus on a way to conclude
our work. Associated changes to deliverables
were also made.

To-Be-Resolved:

Keep multi-master and single-master replication profiles
as deliverables? Or remove them.

Mandatory (?) Replica Management document title is
now somewhat misleading. Perhaps we should change it to
*Recommended* Replica Management?

Both of these issues need to be discussed on the mailing
list.

Any other comments on the WG charter are welcome also.

I'm setting deadline for the WG to conclude discussion on revising
the charter. 

Please post all comments to the WG mailing list or send directly
to John Strassner and myself no later than:

	1700 ET on Monday, March 7, 2003

I will post a final revision reflecting WG consensus to the list
on March 8, 2003. After incorporating final comments (to be sure
I didn't reflect anything incorrectly), this version will be
submitted to the Applications Area Directors for consideration
on March 15, 2003.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email protected]

http://www.dsi-consulting.com

-----------------------------------------------------------

LDAP Duplication/Replication/Update Protocols (ldup)

Chair(s):

Chris Apple <[email protected]>
John Strassner <[email protected]>

Applications Area Director(s):

Ned Freed <[email protected]>
Ted Hardie <[email protected]>

Applications Area Advisor:

Ted Hardie <[email protected]>

Mailing Lists:

General Discussion: [email protected]
To Subscribe: [email protected]
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. This group
was originally chartered to 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 was 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 were
the domain of other working groups. Because the responsible
WG failed to achieve consensus on a standard access control
model for LDAPv3, the LDUP WG formed a design team to explore
the issue of how to address the lack of such a model
in the context of LDAPv3 replication. This design team made
recommendations to the working group. The working group
considered these recommendations and consensus was
established on addressing these recommendations in
the context of revising other working group deliverables
rather than adding new deliverables specific to access
control for replication. Largely because of the lack of
a standard access control model for LDAPv3, the working
group also established consensus on pursuing an experimental
or informational publication path for a majority of working
group documents formerly intended to become proposed standards.

The new replication architecture supports 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.
Done	  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed
Standard.
Done    Revise LDAPv3 Client Update Protocol I-D.

APR 03  Revise LDAPv3 Replication Information Model I-D.
APR 03  Revise LDAPv3 Client Update Protocol I-D.

MAY 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
MAY 03  Revise LDAPv3 Replication Architecture I-D.
MAY 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
MAY 03  Revise LDAPv3 Mandatory Replica Management I-D.
MAY 03  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed
Standard.  

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  LDAPv3 Replication Information Model I-D goes to WG Last Call as
Informational.
JUN 03  LDAPv3 Replication Architecture I-D goes to WG Last Call as
Informational.

JUL 03  Revise LDAPv3 Single-Master Directory Replication Profile I-D.
JUL 03  Revise LDAPv3 Multi-Master Directory Replication Profile I-D.
JUL 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
JUL 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
JUL 03  Revise LDAPv3 Mandatory Replica Management I-D.
JUL 03  Evaluate Deliverables Status

AUG 03  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as
Experimental.
AUG 03  LDAPv3 Replication Information Transport Protocol I-D goes to WG
Last Call as Experimental.
AUG 03  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
Experimental.

SEP 03  LDAPv3 Replication General Usage Profile I-D goes to WG Last Call as
Informational.
SEP 03  LDAPv3 Single-Master Directory Replication Profile I-D goes to WG
Last Call as Informational.
SEP 03  LDAPv3 Multi-Master Directory Replication Profile I-D goes to WG
Last Call as Informational.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email protected]

http://www.dsi-consulting.com