RE: naming contexts

Kurt,

Kurt D. Zeilenga wrote:
> At 11:35 PM 2001-12-05, Steven Legg wrote:
>
>
> >Kurt,
> >
> >> It seems to me that the definition of a "naming context"
> >> in LDAP/X.500 makes little sense in the face of multi-master
> >> replication.  A LDAP/X.500 naming context is subtree of
> >> entries held in a single master DSA.
> >>
> >> Consider three DSAs A, B, C where
> >>       A masters subtree X
> >>       B masters subtree Y
> >>       C masters subtrees X and Y, and
> >>       Subtrees X and Y are adjacent.
> >
> >>From what follows, I assume that Y is subordinate to X.
> >
> >> If A and B are masters and C is a shadow of each,
> >> LDAP/X.500 says that
> >>       A holds context X, B holds context Y, and
> >>       C holds contexts X and Y.
> >
> >C holds a shadow copy of contexts X and Y.
>
> Yes, but the distinction here is what values go into
> the root DSE namingContexts attribute of each server.
>   A publishes the name of the vertex of X.
>   B publishes the name of the vertex of Y.
>   C publishes the names of the vertex of X and Y.

Strictly speaking, C holds no naming contexts because it only
has shadow entries. Its namingContexts attribute should be absent.

Note that X.501 and X.525 aren't entirely consistent in how they
refer to shadow copies of naming contexts. More often than not
the implication is that a naming context is necessarily made up
of master entries.

> >> If C masters X and Y and A and B are shadows,
> >> LDAP/X.500 says that:
> >>       A, B, C holds context X
> >
> >C holds context X, which is now the union of the subtrees X and Y,
> >i.e. there is no longer a context Y. A holds a shadow copy of a
> >portion (subtree X) of context X. B holds a shadow copy of a
> different
> >portion (subtree Y) of context X.
>
> Yes,
>   A,B,C publishes the name of the vertex of X.

A and B are shadows so they don't hold any naming contexts.
That's why I wrote "a shadow copy of ... context X".

>
> >>
> >> If A, B, and C master the subtrees they hold, which
> >> contexts does LDUP say they hold?
> >
> >Having an entry mastered by more that one master DSA doesn't
> invalidate
> >the definition of naming context as far as I can see, but we do need
> >to be a bit more careful how we phrase things.
> >
> >A holds a naming context with the context prefix being the
> root of the
> >subtree X. B holds a naming context with the context prefix being the
> >root of the subtree Y. C holds a naming context with the
> context prefix
> >being the root of subtree X, the same root as A but with a
> superset of the
> >entries.
>
> You imply that context prefix information is not replicated
> between masters

I don't see how you arrived at that conclusion. I expect A and C will
receive context prefix information from the DSA(s) mastering the immediate
superior of the root of subtree X, possibly via each other. B will receive
context prefix information from A and C, since they both master the
immediate
superior of the root of subtree Y.

A, B and C effectively have a read-only replica of their respective
prefix information.

BTW, URP was designed to handle the situation where context prefix
information comes from multiple sources.

> and the definition of a context is local to
> each master.

Pretty much.

>
> There are three basic ways one could define naming contexts
> in face of multi-master replication.
>         a) contexts are determined at each master
>         b) contexts are determined across all masters
>         c) contexts are determined at one master
>
> I note that in single-master replication, naming contexts are
> defined consistent with all three.  In multi-master, you need
> to choose one.  You appear to choose a), yes?

Yes, and for b) I use replication contexts.

>
> >For LDUP we're okay if we say we are replicating
> "replication contexts"
> >rather than "naming contexts".
>
> Yes, one could consider the X and Y subtrees as "replication
> contexts".
>
> >C can be said to hold two adjacent replication contexts (for
> subtree X and subtree Y).
>
> Yes.  One could rephrase the question in terms of replication
> contexts, not subtrees.
>
> I think you are saying that where a server masters multiple
> adjacent replication contexts, these replication contexts
> comprise one naming context on that server.  Yes?

Yes.

Regards,
Steven