[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internal WG Review: Recharter of LDAP Duplication/Replication/Update Protocols (ldup)
OK, thanx for the reply. Sounds fine.
jak
----- Original Message -----
From: "Chris Apple" <capple@dsi-consulting.net>
To: "'James Kempf'" <kempf@docomolabs-usa.com>; "'The IETF
Secretariat'" <ietf-secretariat@ietf.org>; <iesg@ietf.org>;
<iab@ietf.org>
Cc: <john.strassner@intelliden.com>
Sent: Wednesday, May 07, 2003 2:12 PM
Subject: RE: Internal WG Review: Recharter of LDAP
Duplication/Replication/Update Protocols (ldup)
> 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.
>
>