Discussion: Subentries and Administrative Areas, and draft-ietf-ldup-subentry-04.txt

["Ed Reed" <eer@OnCallDBA.COM>]

To refresh people's memories of the discussion in Pittsburgh, here are the notes from the LDUP WG meeting there addressing the administrative area / subentry discussion...
=================================================
5. "LDAP Subentry Schema"
http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry
-03.txt
Editor(s): Ed Reed

Basic problem is that the presence of a subentry causes an
administrative area to be defined. So the administrative
area may not exactly coincide with the naming context. The
subentry document needs to be updated to define what is
meant by each of these terms. The management of
administrative areas, and how this differs (if at all) from
the management of naming contexts, needs to be documented.

This challenges us to as to whether replication needs
semantic understanding of administrative areas. This seems
like a very thorny issue, and it was suggested that we treat
this as a version 2 problem in order to make progress with
the existing definition of LDUP. This draft will be revised
to make scoping of LDUP subentry more clear.

Open issue raised by Kurt is to use a control instead of a
filter mechanism to make subentries visible. This issue has
been posted to the list.

Action: The next revision of this draft will be published by
the end of October.
============================================
Now, you'll notice that I've asked to have published the -04 version
of the document, which includes the specification of an
LDAP control (with no arguments) intended to behave in
much the same way as the subentries ServiceControl argument
of X.511 Search and List operations.

Here, then, begins the discussion about administrative areas,
in the hopes that something simple will fall out quickly.

I confess that my thinking has always approached naming
contexts as being partitions of the namespace, and providing
natural boundaries for a corresponding replication administrative area.

The discussion at Pittsburgh, though, drove home to me that while
that simplification might well suite replication, other administrative
areas (schema, access control policy, application-specific whatever)
are not inherently limited to working within a naming context, may 
in fact overlap several contiguous naming contexts, and may not
cover all of one or more of the naming contexts it does overlap.

In other words, other administrative area definitions are likely to be
arbitrary and completely orthogonal to the ones defined for
replication.  Or at least its certain that we'll find some that are.

However, there's an important definition in [X.501] - autonomous
administrative domain - which indicates that they are non-overlapping.
That might give us leeway to simplify matters.  Certainly, for the purposes
of LDUP, the replication areas are, indeed, non-overlapping.

Further, both inner administrative areas and specific administration areas
are both bounded by (e.g. contained within) one of the non-overlapping
autonomous administrative domain.

So, I think what I"m proposing is that the namingContext auxiliary class
that LDUP Arch defines is the "autonomous administrative point", and
the subentries we're defining MIGHT be tied to that.  Such an evasion
(for that is surely what it would be ;-) would leave for future work
the definition and management of specific administration areas (SAA) which
could then partition the autonomous administrative area, and the
inner administrative areas which in turn partition the SAAs.

Do I have that right?

Would such an approach be satisfactory?  And, yes, I'd be perfectly
happy defining the bare minimum required right now.

Ed