RE: Families of Entries

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

David, all - comments in line.

> -----Original Message-----
> From:	David Chadwick [SMTP:d.w.chadwick@iti.salford.ac.uk]
> Sent:	Wednesday, 13 January 1999 7:50
> To:	Alan Lloyd; ietf-ldapext@netscape.com
> Subject:	RE: Families of Entries
> 
> Date forwarded: 	Mon, 11 Jan 1999 21:45:34 -0800 (PST)
> From:           	Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
> To:             	ietf-ldapext@netscape.com
> Subject:        	RE: Families of Entries
> Date sent:      	Tue, 12 Jan 1999 16:25:05 +1100
> Forwarded by:   	ietf-ldapext@netscape.com
> 
> > 
> >  Dear all, just a few comments on the family of entries issues
> > and compund attributes.
> > 
> 
> thankyou for taking the time to comment
	[Alan Lloyd]  No worries mate

> >  The requirement is very real having collection of entries and
> > parent/child concepts. In addition compound attributes have wide
> > utility.
> > 
> >  some points:
> >  a) Building Parent/Child Definitions
> >  The way in which parent/child entries are built are related to
> > operational functionality desired from the directory service in line
> > with business models. Eg a person entry may have many roles, and
> roles
> > may be supported by many people. Also people report to many managers
> and
> > managers may be a person (a leaf entry) that is responsible for many
> > organisations/units (as represented higher in the directory).
> > 
> 
> this was not the functionality we were trying to support in families.
	[Alan Lloyd]  However, it is a requirement in directory systems
for military, commercial and ISP type services. And related/grouping of
entries are similar issues.

> >  In creating families of logically dispersed but related
> > directory entries we need to understand the distributed and
> operational
> > management and requirements behind that.
> 
> Again, it was not envisaged in the families model to support widely 
> dispersed but logically related entries. Rather it was supporting a 
> single entry having collections of attributes, and putting these 
> collections together, below the entry in convenient child collecting 
> pots.
	[Alan Lloyd]  F.510 as you say provides hierarchial defintions
for families/groups which are in fact unbounded re distributed DSAs.
However, it must be noted that if one is in the business of dealing with
all the issues of distributed directories which include DSP, LDAP server
interconnection, knowledge, access controls, search and list results
correlation, etc that an mechanism that groups entries must be
engineered to support inter and cross DSA operations. This effort is
needed in order to provide seamless directory system services. The
engineering in some of these cases becomes quite complex .. naturally.
And the avoidance of distribution in the LDAP development and letting
the client do all this - is symptomatic of issues.

> > As it is easy to create a single
> > instance of a mechanism and define it in ASN.1 and apply that in a
> single
> > server, but slightly more difficult to engineer that into
> distributed
> > environment that scales well - as well as understand the operational
> > resource that will be needed to run the system.
> > 
> 
> there is no requirement (currently) to distribute children of
> families, they
>  will always be in the same server as their ancestor.
	[Alan Lloyd]  Not being a requirement is not true in all cases.
As stated the whole issue of contexts and entry/attribute value
relationships constrained by DIT naming, across multiple DSAs or in
logical groups is a frontier that is being worked on. Its all part of
the distributed information services requirement. Split entries is one
aspect of this.
	I always get concerned when a simple mechanism is added to sole
a simple part of a problem, because one always ends up with a pile of
simple mechanisms that dont quite do what one wants.  [Alan Lloyd]  I
prefer a systemic view of the entry relationship issues for a
distributed environment and then engineer the optimum mechanisms.As said
there is a number of object/entry realtional issues emerging with
directory services and supporting relational approaches/processes may be
more appropriate.

	I quite like the idea of "matching rule" agents and other
context relevant directory enabled processes that can be distributed
around the directory service. That way the directory itself does not get
compounded or polluted with tons of different search and relational
pointers, schema definitions, etc. The few organisations I have spoken
to about this quite like the idea and the benefits of the process and
operational architecture.

>   >  In fact the operational resource will be the same style to
> > manage that of other directory relational/name based attributes such
> as
> > URLs, DNs-Role Occupant, See Also, Group of Names...., etc. So we
> could
> > just be adding a mechanism that may already be supported with normal
> entry
> > attributes.
> >  And all that needs to be developed is the searching and matching
> > rule processes around these "relational" attributes (as per the
> F.510
> > service model).
> > 
> 
> in fact, the controls are there to support searching and matching on 
> families of entries, as if they were a single entry
	[Alan Lloyd]  understand - but once one has done this, the next
requirement will be for it to work across a distributed system.

> >  b) Total Scope of Directory Searching and Information Management
> >  With Family of entries mechanisms we now have a directory model
> > that is distributed and related by name containment (the DIT),
> grouped by
> > schema definitions, access controls, collective attributes
> (subentries),
> > accessed through contexts (time of day, language, etc) grouped by
> > replication requirements, organised operationally by logical
> hierachy-
> > family definitions and from a business/user information (value)
> > perspective entries are related through See Also, Role Occupants,
> Group of
> > Names, Mail Lists, etc. In addition subtyping of attributes may be
> used -
> > so all in all directory searching and information management can
> become
> > complex.
> > 
> >  I tend to think that X.500 object - hierarchy approach has a
> > great deal to offer at the all levels of the tree. But at the lower
> > levels, a relational model approach may required. Both in terms of
> > information definition and directory engineering. So comments are
> > invited here.
> >  Note the issues re Multiple Service Providers and split entries
> > and how relational search processes can solve that.
> > 
> > 
> >  c) Multiplexed Family Relationships
> >  The mechanism currently defined seems to be a single value
> > operational attribute for each entry for the Hierarchy Info.
> 
> the current spec uses the object class attribute to denote parent-
> child relationships.
	[Alan Lloyd]  Yup

>  > This in the
> > ideal world, should be multi-valued as a child entry may have many
> parents
> > and parents may want logical groups of children.
> > 
> > 
> It is correct to say that many entries may want to share the same 
> collection of attributes, but that is done currently by either copying
> 
> the collection into each entry, or having a see-also or some other 
> pointer, or collective attributes in a subentry. the same 
> mechanisms can be used for families. Alternatively logical 
> groupings of children can be done via a new object class. But there 
> is no way currently for any entry to have multiple parents, so 
> families are no different to normal entries in this respect.
	[Alan Lloyd]  My point is stated from dealing with the
information issues of large companies and what sort of information
relationships seem to be emerging. 
	I dont quite like defining an information  mechanism and saying
that is the rules of how a business must work. eg. I may report to 5
project managers and my salary is managed by HR/admin. I have by
definition multiple parents.
	So I get concerned when a mechanism is defined that does not
quite deal with the problem.

> >  d) Cross-Subordinate DSA management.
> >  The way in which cross DSA boundaries are managed in terms of
> > subentries (collective attributes, schema, service/search
> definitions,
> > etc) adding entries, etc in a set of distributed-subordinate DSAs is
> via
> > DOP. It follows that in theory that if a DSA sibling is added as
> another
> > DSA. Then the parent and sibling entries in other DSAs will require
> > updating. How this is done is a distribution - management issue that
> needs
> > to be looked at.
> > 
> 
> No, I dont propose to ever split families up between DSAs. there 
> are enough broken homes in the real world without introducing 
> more in the DIT :-)
	[Alan Lloyd]  See comment above. Any mechanism defined by the
LDAP or X.500 work must be reviewed for its operation in a distributed,
interoperable environment. Otherwise we will end up with very complex
clients with bespoke servers and the users and the system operators will
have to manage all the functional, information and relationship
boundaries between each component. IMHO - not the way to go.

>  In closing, the requirement for family entries and compound
> > attributes is real.
> >  However, the mechanisms proposed are logical but should we
> > debate the compound attribute area and relational /matching rule
> areas to
> > see if these requirements can be met in a different way.
> > 
> > 
> 
> There is a hierarchical relationship attribute proposed in the F.510 
> work that does allow widely disparate entries to be related together 
> hierarchically. However, this is completely separate from the 
> families approach. Are you mixing the two up?
	[Alan Lloyd]  The two are very related. If one takes the first
step for parent child OCs the next step is to do the hierarchial
definitions. In a distributed DSA system, both should be engineered to
deal with cross DSA issues and their management.
	regards alan
> David
> 
> >  regards alan
> > 
> > >  
> > 
> > 
> 
> 
> ***************************************************
> 
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> Mobile +44 370 957 287
> Email D.W.Chadwick@iti.salford.ac.uk
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string A7OX-K3QT-JPTU
> 
> ***************************************************