RE: LDAP subentry alignment with X.500 subentry

["Albert Langer" <Albert.Langer@Directory-Designs.org>]

[Albert]
LDAP standards must not unnecessarily limit implementation choices. Filter
  specifications on object classes work with either model, since every entry
  knows its object classes and can easily calculate an arbitrary filter on
  them quickly when determining visibility during searches.

[Robert]
Albert, doesn't an entry know the other attributes that it contains as well
and so could evaluate an arbitrary filter ?
[Albert]
Sorry, I should have said "the (structural) object class of an entry is
fixed and therefore the set of applicable subentries does not need to be
recalculated on every search". With general filters such a calculation would
be needed on every search, for every subentry that has a parent within the
base of the search applied to every entry within the scope of the search.
This is multiplying the cost of a search by the number of potentially
applicable subentries (not just the number of actually applicable
subentries).

[Albert]  General filters
  really only work with a traversal based implementation and are basically
  just an attempt to substitute regexp evaluation on path names familiar to
  centralized web administrators for a serious admin model that can actually
  be delegated. The apparant additional flexibility is illusory since it
[Robert]
Don't catch this--a general filter refers to values of attributes within the
entry, not the dn of the entry.  As I pointed out above, users of our
directory make use of this "illusion" all the time.
[Albert]
Whoops, I was arguing against the use of regexp path based ACIs as used in
UMich derived implementations. As you say, this is irrelevant to your
suggestion for (entry) attribute based filters (assuming that a "generic"
filter does not treat dn as an attribute). That's what comes from responding
from "off the top of my head". My other argument above still stands.


[Robert]  For the second question, "what is so great about using subentries
for acis?", I think Alan's response was clearest.  For my own benefit I've
tried to distill (quite a lot!) the main points to the points listed below.
I don't dispute them, but I would say that the "aci attribute" approach also
allows seperation (it's an operational attribute) and delegation (you've got
rights to that attribute or not)...though not to the same extent as the
subentry approach.
[...]

[Albert] I've just realised this topic is across ldap-ext as well as ldup.
I'm not subscribed to ldap-ext and don't have time to be at the moment, so
I'm not plannning to comment further.

For the record though, I believe that:

1. The LDAP subentry proposal is adequate for current LDUP needs. It may be
more than adequate because allowing nested families of subentries may not be
strictly necessary since the replication agreements children of subentries
contain the dn of the replica they apply to. It also appears to still rely
on special case semantics for the meaning of a child subentry of replica
entry. Changing the structure rules is not a minor variant and if done I
would prefer to see it done more fully as in:

 Chadwick, D.W., "Compound (Families of) Entries", Internet-Draft,
      draft-chadwick-families-00.txt, (expired) 5 December 1999.

Ed's argument for a subset of X.500 rather than a superset is convincing.
Its application to a final call for endorsement of a superset by varying
structure rules is not convincing. But somebody has to either object now or
hold their peace. I'm sticking to my objection to the replication
requirements but holding my peace on subentries. If you want a different
superset you need to object now.

2. There will be future LDUP needs for subtree specifications related to
management of the creation of new replication areas. However this is beyond
the current scope.

3. LDAP-EXT ACI ought to have requirements for Directory Access Control
Domains, which need subentry specifications with object class filters. Not
having them severely complicates simple things like delegating management of
printers to printer operators across organizational unit boundaries as well
as across both distribution and replication boundaries. I pointed this out
at the Melbourne IETF but I don't have time to pursue it.

4. Issues like LDAP subentries are quite naturally across both WGs. In my
view there is a vital need for coordination of issues like transactions and
ACI across both groups. The current replication proposals from LDUP will
impede if not prevent any deployment of transactions. This however may not
matter as they will also not meet any reasonable requirements for ACI and
therefore are unworkable anyway. This is independent of whether ACI should
include DACDs. Any workable ACI MUST be replicated atomically and the
current LDUP proposals fail to achieve that, so discussion of attempts to
standardize subentries for ACI as well as for replication within LDUP are
rather pointless.

5. LDAP-EXT has, and should therefore state, a clear requirement for atomic
replication of ACI attributes so that LDUP could stop trying to avoid the
issue. Despite the overlap of authorship of the two requirements documents
there is no indication of any understanding of the impact of non-atomicity
on ACI.

Anyone in LDAP-EXT interested in this should look at my objection and
alternative to the current LDUP proposals:

http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt

Please send or CC any comments to LDUP as I won't see them in LDAP-EXT.

Seeya, Albert