[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LDUP WG Charter
Thanks Chris.
It is hard to comment on something which compounds the problems with
more "mechanisms" rather than solving the system deficiences abounding
the industry with LDAP.
notes follow:
-snip
>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:
The word distributed in the above para is used in the physical sense not
in the directory naming context sense.
Distributed directories are interconnected servers that have a
distributed naming context.
If you mis use words like that, the more uninformed will assume that
LDUP cures distribution issues which to date have meant that all LDAP
(non X.500) severs need their information replicated to everywhere.
Which as I have said is a broken unscaleable concept.
eg I want to authenticate Users on an expanding directory system
User A has their name/password in their entry in server A.
A wants to access B. Therefore we must copy A's entries to B.
B wants to access A. Therefore we must copy B's entries to A.
C server wants to connect to the system with C's users.
C wants to access A and B. Therefore we must copy C's entries to A & B.
A wants to access C. Therefore we must copy A's entries to C.
B wants to access C. Therefore we must copy B's entries to C.
The UK now wants to talk via the directory system to the US, the Pac Rim
wants to talk the rest of the world.. Now we have to copy all things to
all people in all servers - and manage the people migration/mobility
issues...across the whole world.
I do not know where this replication push is coming from nor do I
understand why LDAP server suppliers are even insisting on it.
It is obvious that those trying to deploy such products must have to
grit their teeth when asked how do I connect 10 of these LDAP server
things together and how do I keep them effective..How many humans do I
need. What happens if I want to access other directory systems?
>
> 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.
Is this multi master - all MM modes must ensure synchronous operation.
snip
>
>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)
This will probably need the notion of admin points, subentries and DSE
types - eg master copy entries.
>
> * 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
Not in love with replicating zombies and tomestones and grave yards -
particularly in MM mode - that will hurt the implentors - but thats just
a view.- But to get any form of consistency into the model for
replication one needs a DIT management model - see X.500.
>
> * 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
But this is operation on object focussed - not a bulk atomic protocol as
the LDAP ext have discussed - It will be difficult to turn a object
operation protocol into an atomic bulk protocol - without making more of
a mess of LDAP than what it is. X.500 - DAP, DISP and DSP all for very
good reasons.
But developing systems that way is the choice of the vendors isnt it.
As a point - the more one puts into LDAP the more complex and the more
incompatable and the moore unreliable the client and the servers will
become.
Seperate protocols for different things are good - particularly when
those diffrences relate to object oriented interactions and bulk atomic
inter server transactions.
regards alan