[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LDUP WG Charter
Chris,
As a relative newcomer in the integration and implementation of directory
solutions (brought about by the success of LDAP as the directory access
protocol), could I ask why there is a focus on replication only between LDAP
servers, rather than both distribution and replication? Is there a separate
working group planned for distribution?
Also, I have spent much time coming upto speed on the "state of play" of LDAP
and X500, and as X500 has clearly tackled these requirements in some detail
over the past ten years, has there been much effort by the LDAP community to
learn from and even adopt the DSP and DISP protocols?
It seems strange that so much energy appears to be going into something that,
at least on the face of it, already exists.
Thanks,
Ian.
--
Ian Parrott
Jacobs Rimell Ltd
Office: (44) (0) 171 739 0850
Mobile: (44) (0) 411 527 260
FAX: (44) (0) 171 739 0860
Email: ian.parrott@xxxxxxxxxxxxxxxx
----------
Christopher W Apple wrote:
> Alan,
>
> In your comments (included below) I cannot find a single word
> that I can use to implement a change to the proposed charter.
>
> If you can't make comments that are designed to improve the
> charter and are implementable (e.g., "I suggest changing these
> words to the following..." or "I'm confused by what you mean
> by distributed in this context, could you add text to the
> charter to clarify its definition?"), it would be best if
> you made none at all.
>
> ------------------------------------------------------------------------
> Chris Apple Business Site: AnyWho Directory Service
> Internet Directory Group http://www.anywho.com
> AT&T Labs
> capple@xxxxxxxxxxxxxxxxxxxxxx
> +1 908 582 2409 Tired of slow directories? Try AnyWho.
> ------------------------------------------------------------------------
> >From OpenDirectory.com.au!Alan.Lloyd Sat Jul 25 23:32:37 1998
> >Return-Path: <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>
> >From: Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>
> >To: "'ietf-ldup@xxxxxxx '" <ietf-ldup@xxxxxxx>,
> > "'capple@xxxxxxxxxxxxxxxxxxxxxx '" <capple@xxxxxxxxxxxxxxxxxxxxxx>
> >Cc: "'johns@xxxxxxxxx '" <johns@xxxxxxxxx>,
> > "'capple@xxxxxxxxxxxxxxx '"
> > <capple@xxxxxxxxxxxxxxx>,
> > "'paf@xxxxxxxx '" <paf@xxxxxxxx>
> >Subject: RE: LDUP WG Charter
> >X-Priority: 3
> >MIME-Version: 1.0
> >Content-Type: text/plain;
> > charset="iso-8859-1"
> >
> > Chris - in line with my usual style of response one should not confuse
> >the word "Distributed" with replicated. They are quite different in
> >directory operations. This replication work is of importance to the LDAP
> >server community who have to replicate everything to everywhere just to
> >do authentication of users to many servers.
> >Mind you the issue of cert path processing is still impossible in this
> >case.... :-(((
> >
> >As you know I think like most out here that replicate everything to
> >everywhere approach is operationally broken.
> >
> >As most are now saying now, LDAP is Hand-draulic ie what it does not do
> >- namely distribution and mutual authentication then humans have to with
> >LDIF, manual work and massess of replica utilities AND the bigger the
> >system gets the worse it becomes.
> >
> >Never the less some will require this but pehaps the urgency is to look
> >at scale.
> >On the other hand - one can see that most directory oriented companies
> >are realising that LDAP servers dont do much for "distributed" services
> >and their users and are going down then X.500 path which you know
> >already replicates quite well.
> >
> > I think the issue that should be addressed by LDAP servers suppliers is
> >that this will put them even further back behind X.500 distributed
> >systems.
> >
> >In addition one only has to say with 10 ldap servers and 10 replicas to
> >be managed to everywhere one needs a few more staff - and thats enough
> >to put people off.
> >
> >
> >But thats a choice eh?
> >regards alan
> >
> >----------
> >From: capple@xxxxxxxxxxxxxxxxxxxxxx
> >To: ietf-ldup@xxxxxxx
> >Cc: johns@xxxxxxxxx; capple@xxxxxxxxxxxxxxx; paf@xxxxxxxx
> >Sent: 7/26/98 11:02:55 AM
> >Subject: LDUP WG Charter
> >
> >The charter John Strassner and I would like to send up for IESG review
> >follows. We'd like to limit the comment period to two (2) calendar
> >weeks.
> >This period starts now, 7/25/1998, and ends on 8/11/1998.
> >
> >Please post comments on the list.
> >
> >After the comment period, we will incorporate changes as concensus
> >indicates and send to the Apps Co-ADs with a request for IESG review
> >and approval to create the LDUP WG.
> >
> >John Strassner
> >Chris Apple
> >
> >IETF LDUP Proposed WG Co-Chairs
> >
> >Charter
> >
> >LDAP Duplication/Replication/Update Protocol(ldup)
> >
> >Chair(s):
> > Chris Apple <capple@xxxxxxx>
> > John Strassner <johns@xxxxxxxxx>
> >
> >Applications Area Director(s):
> >
> > Keith Moore <moore@xxxxxxxxxx>
> > Patrik Faltstrom <paf@xxxxxxxx>
> >
> >Operations and Management Area Advisor:
> >
> > Patrik Faltstrom <paf@xxxxxxxx>
> >
> >Mailing lists:
> > General Discussion: ietf-ldup@xxxxxxx
> > To Subscribe: ietf-ldup-request@xxxxxxx
> > In Body: subscribe
> > Archive: http://www.imc.org/ietf-ldup/
> >
> >Description of Working Group:
> >
> >As LDAP becomes more widely deployed, replication of data across
> >servers running different implementations becomes an important
> >part of providing a distributed directory service. However, the LDAP
> >community, to date, has focused on standardizing the client-server
> >access protocol. Therefore, this group will standardize master-slave
> >and multi-master LDAP replication as defined below:
> >
> > 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.
> >
> > 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.
> >
> >Our approach is to first develop a set of requirements for LDAP
> >directory replication and write an applicability statement defining
> >scenarios on which replication requirements are based. Once the
> >requirements and applicability statement have been drafted, the
> >working group will harmonize vendor/vendor-team replication concept
> >proposals; such concept proposals will be constructed in such a manner
> >as to support all forms of replication mentioned above. Each proposal
> >will include provisions allowing functional decomposition of
> >multi-master
> >replication into a proper subset required to implement master-slave
> >replication. After vendor replication concept proposals have been
> >harmonized, a single replication architecture document will be
> >published.
> >
> >Six areas of working group focus have been identified through
> >LDUP Engineering Team discussions:
> >
> > * Abstract Model of LDAP Replication
> >
> > This would document a general-purpose LDAP replication
> > architecture, define key components of this architecture,
> > describe how these key components functionally behave,
> > and describe how these components interact with each other
> > when in various modes of operation)
> >
> > * LDAP Replication Information Model
> >
> > Schema and semantics of information used to operate,
> > administer, maintain, and provision replication between
> > LDAP servers. Specifically, this document will contain
> > common schema specifications intended to facilitate
> > interoperable implementations with respect to:
> >
> > + replication agreements
> > + consistency models
> > + replication topologies
> > + graveyards, tombstones, and zombies
> > + administration and management
> >
> > * LDAP Replication Information Transport Protocol
> >
> > LDAP extended operation and control specifications
> > required to allow LDAP to be used as the transport
> > protocol for information being replicated
> >
> > * 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 LDAP extended
> > operations, controls, and/or new schema elements.
> >
> > * Conflict Detection and Resolution Procedures
> >
> > Procedures for detection and resolution of conflicts
> > between the state of multiple replicas that contain
> > information from the same unit of replication.
> >
> > * Profiles
> >
> > Including the Abstract Replication Model, Information
> > Model, LDAP Protocol Extensions, and Conflict Detection
> > and Resolution Procedures for:
> >
> > + Master-Slave LDAP Directory Replication
> > + Multi-Master LDAP Directory Replication
> >
> >Milestones:
> >
> >May 1998 Directory Replication Requirements and Applicability
> > Statement I-D Published.
> >
> >May 1998 Vendors publish replication concept proposals to
> > LDUP Engineering team mailing list.
> >
> >Jun 1998 Harmonization of vendor replication concept proposals
> > is complete.
> >
> >Aug 1998 Directory Replication Requirements and Applicability
> > Statement I-D goes to WG Last Call as Informational.
> >
> >Aug 1998 Abstract Model of LDAP Replication (based on the
> > concensus of the LDUP Engineering Team) is published
> > as an I-D.
> >
> >Sep 1998 LDAP Replication Information Model is published as an I-D.
> >
> >Sep 1998 LDAP Replication Information Transport Protocol is
> > published as an I-D.
> >
> >Oct 1998 Abstract Model of LDAP Replication goes to WG Last Call
> > as Informational.
> >
> >Oct 1998 Mandatory LDAP Replica Management is published as an I-D.
> >
> >Oct 1998 Conflict Detection and Resolution Procedures is
> > published as an I-D.
> >
> >Nov 1998 LDAP Replication Information Model goes to WG Last Call as
> > Proposed Standard.
> >
> >Nov 1998 LDAP Replication Information Transport Protocol goes to
> > WG Last Call as Proposed Standard.
> >
> >Dec 1998 Master-Slave LDAP Replication Profile is published
> > as an I-D.
> >
> >Dec 1998 Multi-Master LDAP Replication Profile is published
> > as an I-D.
> >
> >Jan 1999 Mandatory LDAP Replica Management goes to WG Last Call
> > as Proposed Standard.
> >
> >Jan 1999 Conflict Detection and Resolution Procedures goes to
> > WG Last Call as Proposed Standard.
> >
> >Mar 1999 Master-Slave LDAP Replication Profile goes to WG Last Call
> > as Proposed Standard.
> >
> >Mar 1999 Multi-Master LDAP Replication Profile goes to WG Last Call
> > as Proposed Standard.
> >
> >