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

[Uppili Srinivasan <uppili.srinivasan@oracle.com>]

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.

Albert Langer wrote:

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