Re: LDAPSubentries comments review and request for last callby LDAPEXT and LDUP working groups

Response:  

LDAP includes, by reference, X.500 subentries, including refinement.

Just use them, if your applications require refinement.

LDAPSubentries are intended to assist in representing policy information
that doesn't require refinement as supported by X.500.

Perhaps LDAPv3bis will clarify the LDAP representation of the X.500
subtreeSpecification, including the various chop semantics, and everyone
will implement them as a result.  

Then the only obsticle will be getting test modules added to the Microsoft, 
Novell, Netscape, et al directory administrator certification test programs so 
there will be a prayer that they'll be used correctly by the 75,000
or so certified directory administrators out there in the real world.

My personal view is that the subtreeSpecification is a neat piece of 
design that requires system administrators to view their application
policy (ACI, Schema, whatever) as a collection of ropes created from
multiple arbitrary threads connecting attributes and entries scattered
throughout a tree (without intersecting or overlapping or leaving
any attribute/entry unconnected).  This multidimensional view
is elegant, powerful, versitile, and pretty totally without the
computational tools needed to inspect, modify, or test whether
the refinements expressed actually relate in any interesting way to
the policy the administrator had in mind when they started refining
their policy.

SubtreeSpecifications appear to be an interesting implementation
mechanism for representing complex policy.  Unfortunately, the
current state of the market place is that developers, who can walk
through the code in their minds to figure out what a thing will do,
too often assume that everyone else can do that, too.

Frankly, I've had enough trouble explaining (over and over and over
again) to information technology consumers why "relational databases
aren't just as good" as hierarchical tree structures for distributed
management policy representation.  Now you want to get them
thinking multidimensionally, too?  

Crawl, walk, run - a lesson taught by real world experience, and
addressed to developers of products, consumers of those products,
and the executive managers of those consumers.  

Technologists who put forward elegant, powerful, versitile and
uninspectable solutions find, in the mass market, that they're
also unpredictable because they'll be used in the wildest, most
amusing ways.

I recommend we not go there.

If the concensus of the group is that we must, then I think we
need to seriously reconsider the advisability of taking LDAPv3bis
forward, and realize that we all should just adopt X.500 in its
entirity.  Kurt and Albert have been correct in their assertions
that LDAP isn't a distributed service, we're turning it into one
by pieces, and the X.500 design (if we need the whole refinement
thing, then we probably need the whole HOB thing as well,
and if we do that, then what's left not to put into LDAPv3bis?)
should be tried instead.  If you can get Microsoft and
Novell to go there, that is...

I for one don't want to encourage LDAP customers to use
refinement in ACI, nor to experiment with multimaster
replication from sparse and fractional replicas.  I think there's
a world of applications (like non-global, in-the-tree schema 
management), in the distributed 
management world, that do not require that kind of power
to be put into consumers hands to use to shoot themselves
in the foot.  But, if the number of customer support phone calls
resulting from having hundreds of thousands of directory
administrators trying to figure out why their highly refined
policy doesn't behave "the way they thought it would"
is a satisfactory definition of success, then go for it!

I'll ask the chairs to decide the concensus of the working group.

Ed



=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <[email protected]> 07/18/01 10:53PM >>>
At 12:24 PM 7/16/2001, Ed Reed wrote:
>So -  I'd like more comments on the administrative model.  Does it work for ACI as LDAPEXT is defining it?  Other applications than just LDUP?  I think it DOES work for LDUP (ie, managing replication areas).

I don't think it works for access controls, subschema,
collective attributes, and likely not for LDUP (consider
sparse replica).  Of course, my definition of "works"
may be quite different than yours.

ldapSubentry can only hold information associated with a subtree.
ldapSubentry, by design, cannot hold information associated with
a subtree refinement [X.501].

Consider a case where the administrator wishes to hold a set
of shared attributes for the collection of entries which are
immediately subordinate to a particular entry (but not the
particular entry).  This cannot be done using LDAPsubentries
as LDAPsubentries requires that each subordinate have a
separate subentry to hold the attributes.  As these attributes
are held in different subentries, they are not shared.  And
further subentries need to be created to break the inheritance
(as the information was to be shared between the immediate
subordinates).   And, of course, needed subordinates are not
automatically created/deleted upon add, delete, and rename.

I believe there is good operational experience from the X.500
community that a subentry subtree refinement mechanism is needed
to allow for effective administration of the Directory.  I
recommend we adapt X.500 subentries, including the subtree
specification mechanism, for use with LDAP.

Kurt