RE: Internal WG Review: Recharter of LDAP Duplication/Replication/Update Protocols (ldup)

["Chris Apple" <capple@dsi-consulting.net>]

Responding below in context.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:capple@dsi-consulting.net

http://www.dsi-consulting.com

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com] 
Sent: Wednesday, May 07, 2003 12:27 PM
To: The IETF Secretariat; iesg@ietf.org; iab@ietf.org
Cc: capple@dsi-consulting.net; john.strassner@intelliden.com
Subject: Re: Internal WG Review: Recharter of LDAP
Duplication/Replication/Update Protocols (ldup)


I found this charter somewhat confusing. I've made some comments
below.

            jak

> LDAP Duplication/Replication/Update Protocols (ldup)
>
> Chair(s):
>
> Chris Apple <capple@dsi-consulting.net>
> John Strassner <john.strassner@intelliden.com>
>
> Applications Area Director(s):
>
> Ned Freed <ned.freed@mrochek.com>
> Ted Hardie <hardie@qualcomm.com>
>
> Applications Area Advisor:
>
> Ted Hardie <hardie@qualcomm.com>
>
> Mailing Lists:
>
> General Discussion: ietf-ldup@imc.org
> To Subscribe: ietf-ldup-request@imc.org
> 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.
>
> Recently, the WG established consensus on a change of
> direction to pursue publication of a standards track
> protocol for LDAPv3 client synchronization, an experimental
> LDAPv3 replication protocol, and supporting informational
> documents. Thus the new work program is largely the same
> as the original work program with one notable exception,
> the LDAPv3 replication protocol is intended to be an
> experimental rather than a standards track protocol.
>
> 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.
>

This paragraph was very confusing to me. It seems like some kind of
history about why the original WG couldn't accomplish its original
objective of doing a standards track protocol, and seems also to
include some prehistory of the original working group. I have some
trouble seeing the  relevence to the goals of the new WG. Is this
paragraph necessary? Couldn't most of this be summarized with a single
sentence or two?

CWA> It could be summarized in a sentence or two, but the WG
CWA> has achieved consensus on representing this information
CWA> as its written above. Prior attempts to summarize this
CWA> information using less text were not thought to be sufficient
CWA> by WG members.
CWA>
CWA> You are correct that this paragraph contains a history
CWA> of why the WG is where it is.
CWA>
CWA> The prehistory information is contained in the existing
CWA> charter.

> 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 Replica Management
>
>          Specifications designed to support 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 A General Usage Profile of the LDAPv3 Replication Architecture,
>        Information Model, Protocol Extensions, and Update
Reconciliation
>        Procedures.
>
> 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.
>

These sound like excellent technical objectives, if somewhat
ambitious.

CWA> OK....are you suggesting a specific change? If not, I don't
CWA> view this comment as actionable.

> 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 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 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 Update Reconciliation Procedures I-D.
>
> JUL 03 Revise LDAPv3 Replication Information Transport Protocol I-D.
>
> JUL 03 Revise LDAPv3 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 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.
>

This schedule sounds very aggressive. The technical objectives cited
above suggest a certain amount of design complexity that might
complicate the design effort unless preliminary work has cleared away
most of the initial uncertainties. Are most of these activities
currently underway? Have all the major controversies been dealt with?
Do the chairs believe this schedule is doable?

CWA> It is intentionally aggressive because the milestones above
CWA> are setting a schedule for the WG to conclude its work on
CWA> deliverables that are fairly mature at this point in time.
CWA> The WG has established consensus that there is value in
CWA> noting known areas of controversy/contention as unsolved and
CWA> publishing the existing documents as non-standards-track with
CWA> LCUP being an exception. All of the work has been going on
CWA> for some time. This is a charter revision and doesn't represent
CWA> new work - only a change in standards track status for certain
CWA> documents, addition of some text to preserve the history of the
CWA> path the WG took in getting to this point, and resetting of dates.
CWA> There were also two deliverables trimmed from the existing charter
CWA> because no one could come up with a cogent statement supporting
CWA> the work associated with them.