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

From: "Ed Reed" <[email-masked]>
Date: Sat, 04 Nov 2000 20:24:52 -0700

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

---

From: "Albert Langer" <[email-masked]>
Date: Sun, 5 Nov 2000 18:12:37 +1100

[Ed]

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

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

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

[Ed]
Such an evasion

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

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

---

From: Uppili Srinivasan <[email-masked]>
Date: Sun, 05 Nov 2000 15:06:59 -0800

Ed and Albert:

Thanks for re-initiating this discussion.

I think there is no real workable way to evade the issue of replication of
administrative information associated with services whose administrative
boundaries are independent of that of replication.  I agree with Albert's
comments and his suggestions for augmenting the LDUP architecture document,
including treatment of naming contexts.

At Pittsburg it was decided that the LDUP model (architecture) document should
be updated to present a resolution for conflicts that arise from the fact that
ACL administrative areas are independent of replication administrative areas
(the latter is defined to coincide with "naming context" boundaries).  But the
actual issue, as you have stated,  is not just specific to ACLs.  So a clear
general frame-work for this has to be spelled out in the LDUP model document.

The following comments Albert has made are especially worth noting.  (Some of
these have been made before by others as well):

-  LDAP should simplify protocols when and where possible, but must not change
the conceptual framework
-  The conceptual framework for this "future work" was done many years ago for
the X.500 standards

And specifically, w.r.t replication:

-  Actual management could conceivably be deferred .... 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.

With subentry and ACL model drafts progressing, the problems resulting from not
spelling out a conceptual frame-work for administrative areas and their
replication is very evident.

Specifically, I propose we incorporate the following recommendations that Albert
has made to the LDUP model draft:

1)  State that the LDUP replication agreements implicitly requires replication
of those "ancestor" administrative points (including their subentries).
2)  Eliminate the concept of a NC [as defined in the current LDUP drafts ..
where it is indeed confused with replicated area (RA)].   Change the use of NC
to read as RA in other relevant discussions.
3) Paraphrase the namespace partitioning discussion along the guidelines in
X.500.  Cleanup the confusion between NC and replication area in the current
draft.

Also, the only way LDUP can go forward, in this regard, without conflicting with
the future LDAP revision is if we agree now to concretely adopt corresponding
X.500 conceptual frame-work.

Regards,
Uppili.