RE: naming contexts

<eer> comments </eer>

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Kurt D. Zeilenga" <[email protected]> 12/06/01 08:45AM >>>

At 11:35 PM 2001-12-05, Steven Legg wrote:


>Kurt,
>
...

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

<eer> my interpretation is that yes, A, B, and C all publish X as a 
naming context on their rootDSE.  They also will publish X as a 
repliation context on their rootDSE.  B and C will also publish Y as a
replication context on their rootDSE.  

This example is why I was finally persuaded that naming contexts
are different from replica contexts, and that a different rootDSE
attribute was needed to hold the names of verticies of replication
contexts separately from the names of naming contexts.
</eer>

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

<eer> My own personal preference is that naming contexts, as I understand
them, are determined for each server, describing the verticies of subtrees
held by that server.

Clearly, at that point, the naming context doesn't describe a vertix in the
DIT, but rather a vertix in a servers DIB.

Knowledge about subordinate subtrees not held locally are defined, in my
world view, in subordinate entries held by servers holding the immediately
superior namespace to the absent subtree.  

In my world view, those subordinate entries are a special type of replica
of the subordinate namespace - they hold only the name of the vertex
of the subordinate namespace and the replicaSubentries for the replication
area that begins at that vertex.  The replicaSubentries contain accessPoint
and replica type attributes for the server that holds each corresponding replica, 
so that a client can pick a replica of the appropriate type.  Alternatively,
if a server is conducting a subtree search for a client encounters one of the
subordinate entries, it can then refer the client to one of the other servers to 
continue the search.

I think this is the "normal" X.500 use of subordinate entries, though I'm fuzzy as
to whether they're simply "glue" entries or "real" entries in the superior
namespace.  I recall being told at one point that the scheme I'm describing
is similar to the one QUIPU used.  Certainly, it's a style of specific subordinate
entries, not nonspecific subordinant entries (NSSE).

The use of replica toplogy information seems useful, to me, as a natural
result of chosing to store the replica topology information in the directory.

I've not tried to be rigorous in my use of terms, here, but rather to convey
a broad impression of what's desireable.  Distributed operations based on
using this in-the-tree replica topology information need to be rigorously
specified, but alas, I know of no LDAP design group chartered to undertake
such an endeavor.

</eer>

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

<eer>
yes, because that's our interpretation of what people expect to be told by a server when it is asked about the naming contexts that it holds.  And thus, the additional rootDSE attribute to hold information about the replication contexts it holds, which may well list more vertices than the list of naming contexts it holds.
</eer>