RE: naming contexts

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.


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

>>
>> 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 and the definition of a context is local to
each master.

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?

>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?