Subject: Re: Revised work group charter for your review

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 17 Jan 2001 21:38:57 -0500

John,

I put comments below - prefaced with <TJH>

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

"John Strassner" <[email-masked]>@mail.imc.org on 01/12/2001 06:34:56
PM

Please respond to "John Strassner" <[email-masked]>

Sent by:  [email-masked]

To:   <[email-masked]>
cc:   <[email-masked]>, "Chris Apple" <[email-masked]>, Patrik Fältström
      <[email-masked]>
Subject:  Revised work group charter for your review

Hi LDUPers,

below is a revised charter for our workgroup. Chris and I
need your comments asap, so that we can present our new
charter to our AD. Please especially note the new dates for
our delierables. I'd like this review closed as soon as
possible. If anyone objects to review ending next Friday 19
January, please object soon.

regards,
John and Chris

LDAP Duplication/Replication/Update Protocols (ldup)

Chair(s):

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

Applications Area Director(s):

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

Applications Area Advisor:

    Patrik Falstrom <[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
<TJH> - why state the following thing explicitly?  In fact
the current model in the architecture doesn't require
communication with other masters before the update is
performed
</TJH>
   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.

<TJH> editorial, "support" should be "supports" </TJH>
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

<TJH> editorial - add the term "directory"? </TJH>
  Defines the directory 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

<TJH> is it still called "Replication Information Transport Protocol"?
I thought it was just "Replication Transport Protocol"
</TJH>
 o LDAPv3 Replication Information Transport Protocol

  LDAPv3 extended operation and control specifications
  required to allow LDAPv3 to be used as the transport
<TJH> editorial -
change:
  protocol for information being replicated
to:
  protocol for replicating information between servers.
</TJH>

 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
<TJH> editorial -
change:
  the state of multiple replicas that contain information from
to:
  the state of directory information held in multiple replicas
  which contain information from
</TJH>
  the same unit of replication.

 o LDAPv3 Profiles

  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 LDUP WG Chairs will assign one or two persons to be
official
LDUP WG liasons to ITU, to monitor X.500 replication work in
the ITU,
and to coordinate the work of the LDUP WG with similar work
in ITU.

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 Submit I-D on LDAPv3 Replication Information Transport
Protocol.

Done Revise I-D on LDAPv3 Replication Information Model.

Done Submit I-D on LDAPv3 Subentry Schema

Done Submit I-D on LDAPv3 Client Update Protocol

Done Submit I-D on Extended Operations for Framing LDAP
Operations

<TJH> I assume that the 2-digit numbers below correspond to the year,
i.e. "01" means "2001".  Thus, "Jan 01" has not expired yet.
</TJH>

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

<TJH> How can this document go to last call before the architecture
draft???
</TJH>
Jan 01 LDAPv3 Update Reconciliation Procedures I-D goes to
WG Last Call as Proposed Standard.

Mar 01 Submit I-D on LDAPv3 Mandatory Replica Management.

Mar 01 Submit I-D on LDAPv3 Multi-Master Replication
Profile.

Mar 01 Submit I-D on LDAPv3 Master-Slave Replication
Profile.

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

<TJH> Why is this one only informational?? </TJH>
Apr 01 LDAPv3 Replication Architecture I-D goes to WG Last
Call as Informational.

Apr 01 LDAPv3 Subentry Schema goes to WG Last Call (joint
with LDAPEXT) as Proposed Standard.

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

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

<TJH> I don't recall seeing this topic in the list of topics above.
Should something about "Framing" and "Grouping" be added to the
write up above??
</TJH>
Aug 01 LDAPv3 Extended Operations for Framing I-D goes to WG
Last Call as Proposed Standard.

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

Dec 01 LDAPv3 Master-Slave Replication Profile I-D goes t WG
Last Call as Proposed Standard.

Dec 01 LDAPv3 Multi-Master Replication Profile I-D goes to
WG Last Call as Proposed Standard.

Dec 01 Reevaluate Charter and Milestones

Current Internet-Drafts

<TJH> I believe that the -06 version of the replica reqs is now published.
</TJH>
http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-
req-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.t
xt
http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-05
.txt
http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-
01.txt
http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry
-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol
-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-
00.txt
http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcu
p-02.txt

Current RFCs
None