RE: Inheriting / Cacheing / Replicating policy from superioradministrative areas

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

[Ed]
Anyway, that's the idea we came up with.  Discussion is invited, if only to
cause a change in subject on the mailing list ;-)

[Albert]
Quick response for similar reason, as a break while still working on LDUP
final call issues.

I think it should be based directly on X.500 framework for administrative
areas with whatever
LDAP style simplifications can be achieved in those aspects that relate to
operational bindings etc but no departures at all from a common conceptual
framework as to how policy is inherited.

Seems to me that the standards themselves and David Chadwick's online book
about them point to a "natural" description that is very similar your option
5 "sparse replica".

That is to treat admin points very much like "glue" entries necessary to
maintain a connection from a subordinate context to the global tree. You
simply replicate all superior admin points that a replicated area is nested
within like any other glue. Then you use the glue style entries for those
admin points at the replica to drive whatever implementation specific
machinery is used to prioritize and enforce policy in strict accordance with
the X.500 conceptual framework.

If I understood correctly that seems to be what you saying about a "sparse
replica", but integrates it with what's also needed in this context (and has
been all along before dealing
with multi-master) - a framework for directory distribution based on X.500
with detailed
specification of operational bindings, glue entries etc. Administrative
areas can't be defined
independently of that framework without running into the fact that they are
closely connected
to it.

Interesting issue relevant to current other discussions is that I suspect
this replication could be an example where multi-master may be inapplicable
due to the extreme hairiness of allowing for policy update conflicts. That
in turn raises hairy issues about how one could combine single master
partitions (even if only containing such "admin points" and other "glue"),
with multi-master replicas subordinate to them on the same DSA
implementation, with an overlap between
the two at the innermost nested admin point. It also points to the necessity
for actually implementing the LDUP WG charter to provide for single master
as well as multi-master replication (the difference isn't just a "topology"
but involves both conformance levels for DSAs and directory service
replication requirements). Also points to need for replication management
to be standardized with provisions for creating and merging replication
areas etc.

This may also closely relate to schema replication (for which X.500 defines
similar admin
points in the same conceptual framework). There are requirements about
schema replication in the current requirements draft and machinery is needed
to be able to coordinate schema changes with the replication of entries
dependent on the schema changes - but there is no such machinery in the
current architecture drafts. Similar machinery could be needed for
coordination of policy changes.

Any such coordination machinery has to be enforced by the conflict
resolution mechanism and since none is currently specified, none is
currently implemented by URP (whether or not it could do so, given that it
does not retain log information that might be necessary).

Then coordination machinery for any of these aspects is likely to involve
something like the concepts of a "floating" or "failover" single master for
that specific aspect as in the "schema master" and "infrastructure master"
for AD. This is also needed to achieve eventual convegence as there is of
course no way to guarantee that without some means of specifying which DSAs
are currently authoritatively considered to be part of the replication
network and which are excluded from it - otherwise meta-data would grow
without bound while waiting for a failed DSA that isn't
going to come back. Again there is no such machinery in the current
architecture, consequently none in URP and no eventual convergence possible.

Hmm, ... oh well, *some* of that was a "break" and it *is* all relevant to
your original posting, which I have at least refrained from dissecting line
by line ;-)