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

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

[Ed]
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.

[Albert] Replication (and indeed the LDUP WG) clearly does need some
semantic understanding of administrative areas (and also of distribution ...
not to mention atomicity ;-)

Actual management could conceivably be deferred until version 2 and is
really a general LDAP issue rather than a specifically LDUP issue since it
applies even with no replication.

Replication of the managed administration points affecting a replicated area
should not be deferred.

Specifically, entries must be replicated for each administrative point in
the DIT that is an ancestor of the actual replicated area. These are not
just "glue" to form the name, which also has to be replicated, but could
"simply" be carried by the root of the replicated area. They also involve
replicated attributes and subentries with actual administrative information
that can only be applied to entries in the replicated area if it has been
replicated to the DSAs holding replicas of those entries. This is pretty
straight forward - a replication agreement implicitly requires replication
of those "ancestor" administrative points (including their subentries).

For distribution, additional knowledge information about the DSAs holding
NCs below the boundary of a replicated area also needs to be replicated
implicitly with that replication area. Otherwise a DUA cannot be given a
referral to them. That could be less straight forward.

[...Ed]
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.

[Albert]
Not mentioned in the correction below is that the partitioning of the
namespace by NCs is  a partition according to the single master DSA holding
the context prefix. It follows that a DSA cannot hold contiguous NCs, since
they are merged into a single NC by the fact that it holds a single context
prefix for both.

With multi-master, a set of replica DSAs holds the context prefix of a
partition of the namespace, by all holding a replicated area which includes
that entry. But the same set of DSAs need not all hold all the replicated
areas which are part of that partition of the namespace. It is sufficient
that the intersection of the sets of replicated areas they each hold include
that particular replicated area which has the context prefix.

For example an organization (Autonomous Administrative Area) might have
replicated areas corresponding to HQ, regional and local organizational
units, each with their own DSA at a corresponding office. But a single DSA
in say Paris might well hold the replicated areas for the multi-national HQ,
the Paris Region and a particular local office. There is no reason why it
should also have to hold replicas for every other regional or local
organizational unit.

A "simple" approach could just eliminate the concept of an NC, as in the
current LDUP drafts where it is confused with the new concept of a
replicated area (RA). Reading RA instead of NC, the problem seems to just
disappear.

But then who defines the namespace partitioning?

The separate concept of an NC is still needed to administer names.

[Ed]
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.

[SC]
In addition, realistic Directory Access Control Domains add further
complications.

[Ed]
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.

[SC]
The conceptual framework for this "future work" was done many years ago for
the X.500 standards.

LDAP should simplify protocols when and where possible, but must not change
the conceptual framework.

Although the the X.500 standards are pretty unreadable, an excellent
explanation is in David Chadwick's book, available online at:

http://www.salford.ac.uk/its024/Version.Web/Contents.htm

Section 11 of chapter 2 actually succeeds in making the administrative
framework intelligible!

Inner Administrative Areas do not "partition" SAAs since they can be nested
as shown on the right of this diagram:

http://www.salford.ac.uk/its024/Version.Web/Chapter.2/fig2-6.gif

Assuming that actual management can be deferred, definition (by simply
adopting the work already done) should not be deferred.

Simply specify that ancestor administrative points and their subentries are
replicated together with each replicated area. Otherwise replicas simply
would not receive essential context information.

Visualize a "replicated area" as possibly being a smaller triangle within
that nested IAP. It clearly needs to receive copies of each of the ancestor
administrative entries and subentries in that diagram.

[Ed]
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.

[Albert]
A "Directory hosting ISP" could hold the AAA's for numerous organizations on
a single DSA, just as a "Web hosting ISP" holds numerous domains for web
service.

Each would be replicated with internal DSAs of the organization concerned
and with DSAs at other local sites of the ISP to provide global backbone
directory service for those organizations.

It certainly should not follow that they are all a single replicated area
because they hosted on a single DSA.

Not only should the various AAA's not be required to receive replicas of
each other, but some may  only need say 2 replicas at local sites of their
ISP while others may want replicas at more.