Subject: RE: LDAP subentry alignment with X.500 subentry

From: "Albert Langer" <[email-masked]>
Date: Fri, 14 Jul 2000 18:23:16 +1000

[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

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 17 Jul 2000 13:08:52 +1000

Albert,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Albert Langer
> Sent: Friday, 14 July 2000 18:23
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: LDAP subentry alignment with X.500 subentry

[snip]
 
> applicable subentries (not just the number of actually applicable

The specificationFilter of a SubtreeSpecification applies to the
objectClass attribute rather than the structuralObjectClass. Since the
objectClass can contain optional auxiliary object classes that come
and go, a conformant X.500 implementation already has to deal with the
situation where the set of applicable subentries changes.

Some of our customers need to be able to set access controls based on
the non-objectClass attributes of the entry. The way we have achieved
this with X.500 basic access control is to define an auxiliary object
class, with no mandatory or optional attributes, that we use to tag
entries satisfying an implied filter on the entry contents.
SubtreeSpecifications then reference the auxiliary class in their
specificationFilters. The auxiliary class tagging has to be maintained
manually. Being able to filter on arbitrary entry contents in the
specificationFilter would be better.

[snip]

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

Regards,
Steven

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 17 Jul 2000 23:46:40 +1000

Steven,

Thanks for:

a) The correction below.
b) The explanation of why the non-restriction to structural classes is
useful.
c) The explanation of why general filters would be more useful.

Clearly I was wrong about the restriction to object class avoiding any need
to dynamically track which DACDs an entry is in, though I still think it
might be simpler and more efficient than for a general filter, eg some
implementations only having to recalculate when an entry changes its object
class attribute (rarely), rather than for any change.

I'm still not convinced about the advantage of c) over b), although this
certainly does at least diminish one argument against c).

Other reasons are:

1. General principle that LDAP should remain "lighter" than X.500 and
compatible with it. Therefore any superset variations should be demonstrably
necessary, eg to simplify something else, not just desirable. Proper
subentries are demonstrably necessary to simplify access control. As Kurt
pointed out, not providing them will just result in more complex ways of
doing the same thing being required anyway. But "enhanced" subentries are
not demonstrably necessary.

2. What kinds of DACD can be specified should be a matter for schema
administrators (ie "manually" in practice), not for access control
administrators. It really is an issue of maintaining consistent schema (in
this case for access control) so that there is a common understanding of
what each type of DACD actually means. Maintaining that commonality of
understanding of the schema is inevitably and intentionally less flexible
than the changes that other kinds of administrators and end users should be
allowed to make to the directory.

The concept of a DACD is currently less familiar to LDAP administrators, who
are often both schema and access control administrators (whether or not they
understand much about either).  The concept of a general filter is more
familiar to them, but the relative rigidity of DACDs will actually make it
easier for administrators and end users to understand in the long run, as
the point of standardizing these things is to enable full interoperability
over much larger areas than most LDAP administrators are currently
administering, with delegation within those areas.

eg "Allow printer administers to administer printers within this part of the
tree" is easily understood. If it turns out that a different set of
permissions should be granted with respect to color printers, then they are
entries with a different type of behaviour from other printers and should
have their own object class, even if they don't need extra attributes. If
they do not need recognition in the common schema applicable organization
wide as a distinct type of entry, then any variations in types of access
control should be local to the particular part of the tree that perceives
the need for this.

Authority over types of access control should not be delegated unless one is
also willing to delegate authority over schema. Delegation is rapidly moving
down to end users and lower level administrators need a clear and stable
conceptual framework.

If its really inconvenient, lower level administrators can ask schema
administrators to define a new object class. The standards do not prevent
them tagging entries with auxiliary object classes once those classes have
been defined, but only from introducing new ones without coordination. An
implementation might make such tagging unnecessarily "manual", but that it
is not a standards problem.

The goal here is to reduce variation in conceptual framework, not facilitate
it. General filters are intended to, and would succeed in, enabling easy ad
hoc changes to the conceptual framework for administering access controls.
If that was desirable, then general filters would be desirable. As it is
undesirable, they are a bad idea.

3. I suspect that the interaction between general filters, permissions and
priorities is likely to not be well understood, and result in errors when
people are given permission to change an attribute value without
understanding that this will have side effects on access controls.

4. Even with atomicity, I don't think its going to be at all easy to cope
with the interactions between ACI and replication. My error regarding
structural object classes may have resulted from wishful thinking, since it
will be even harder to cope, given that an object can move in and out of a
DACD as a result of a change in its auxiliary object classes. But at least
that only adds one kind of replicated change to worry about, on top of
changes to entry and prescriptive ACI themselves (not to mention group
membership and changes in distinguished name prefixes that can also affect
access controls). Adding potential surprises in permissions resulting from
unsynchronized replication of other attribute values would not be helpful.

In earlier discussions on the LDUP list it was recognized that this problem
of entries moving in and out of the scope of a filter made it undesirable to
allow general filters for specifying fractional replicated areas.

5. Its clear that there is a strong reluctance to introduce proper
subentries at all, despite their obvious necessity for ACI, which goes far
beyond what is immediately needed for LDUP. I would rather see a successful
quick resolution by acceptance of existing standards for subentries, or a
viable subset of them, than a protracted delay in achieving any reasonable
support for ACI at all. (The arguments raised against the current draft by
others already establish that at least some specification of the base and a
filter on object class will be necessary before final call. Adding chop
specifications does not really complicate implementation much, whereas
general filters still does to at least some extent, and would therefore
increase the resistance and consequently the delay for accepting the
necessity for having proper subentries).

BTW If the reference to manual maintenance of tagging below means that your
customers *want* the DACD applicable to an entry to change dynamically with
the ordinary contents of the entry, and you are having to change the object
classes in synchronization with other changes to the entry, then I can only
suggest seeking more sensible customers ;-)

I have assumed above that you were only referring to the manual difficulties
of tagging entries when the customer's conceptual framework changes, not
when the entries change. Implementation tools should allow administrators to
apply a general filter to re-tag entries, without a need for
standardization. A standard DUA should be able to do that just by scripting
to apply the change desired to each entry within the scope of the filter. If
standards were required for directory operations that apply to more than
entry, they would be be for more general changes, not just in relation to
access controls.

Seeya, Albert

[original below]

> applicable subentries (not just the number of actually applicable

[Steven]

[snip]

Regards,
Steven