RE: LDAP replication requirements [virtual attributes]

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From:	Paul Leach [SMTP:paulle@xxxxxxxxxxxxx]
> Sent:	Wednesday, April 29, 1998 6:40 AM
> To:	'ietf-ldup@xxxxxxx'
> Subject:	LDAP replication requirements [virtual attributes]
> 
	snip

	The text below again highlights a few of the referential issues
and the major weaknesses in LDAP - ie. no distribution - no domain based
access capabilities.


	The "virtual" attributes below which can be created by the
server itself or by an admin utility, builds name based inter object
references. Nothing wrong with that - its just very restricted if one
can only do that within one server with the objects within that server.

	X.500 provides a common naming context "cloud" of distributed
directories in which each directory can  perform in a distributed way or
contain replica information. X.500  permits See Also, Role Occupant,
Group of Names (DN) type attributes that can point from one directory to
any other. Ditto with certificate path processing in terms of having a
distributed name path which is resolved within the directory system. ie.
one can build references for use accross the whole directory context.


	All of these above attributes are impossible to deal with in a
disjointed  naming context as provided by (non X.500) LDAP servers.
	It also follows where users are members of other objects that
reside in other LDAP only servers, then referential knowledge must also
be obtained.

	In the replication process what happens re these many
references. Does this mean that any non X.500 LDAP server that uses
externally pointing DN attributes  has to be preconfigured external
references (referrals), and these MUST- must be replicated to the
replica server ?
	What hapens if a replica server is required to reference another
replica of another master server. ie. A replicates to Ar and B
replicates to Br.  and the system admin now wants the B references as
used in A' attributes which are  replicated in Ar to point to Br.

	Given large servers of 100,000 to mmms of entries with: See
Also's Groups, Members, Mail Lists and Certficates, Alias,etc.  Isnt
this LDAP approach to name based directories, with name based references
(attributes) that can exist as a master or a replica that can reference
a master or a replica some where else in the system, somewhat frought
with scaling and configuration management issues .

	A mechanism that defines which attributes to replicate (be they
real or "virtual") between a single server is easy - what happens re
references and dealing with distribution?

	regards alan

> Support for "virtual attributes"
> 
> Example: we have user objects in the directory, and we have group
> objects.
> User objects have a "member-of" property. That property is _not_
> stored --
> for any user object, it is computed dynamically by searching all the
> group
> objects for ones that contain that user object. Thus, updating a group
> object will cause a side effect of changing the values on some user
> object.
> 
> There are lots of other instances if the utility of this kind of
> bahavior:
> the "reports-to" and "manager-of" properties of managers and the
> employess
> that report to them, for example.
> 
> The knowledge of the relationship between these properties is not
> captured
> or capturable  with the current schema mechanism. It has to be
> understood
> "a-priori" by each replica. So, the representation of schema would
> need to
> be enhanced to support replication of virtual attributes.
> 
> Paul