RE: naming contexts

1) I'm pleased to see Kurt referring to a "Primary Master", as I think such a concept is needed to represent the single-master of replica topology information about a replication context.  However,

2) I agree with Steven that what becomes interesting in a multi-master environment is the replication context, not the naming context, held by a server.  Frankly, in the mostly-distributed directories I've worked with, replication contexts were all that were available, since they're more informative about what is actually held, allow clients to piece together a minimal set of servers needed to fully traverse a distinguished name when searching for a named entry, etc.

But here the interesting point - there IS a place for a "Primary Master" when you ABSOLUTELY NEED some data in the DIT to be single-mastered, even if the rest of the data can be multi-mastered.  In my example 1 above, those data are the operational attributes and subentries associated with the definition, description and management of a replication area.

Thus, the Model (Architecture) document and, I think, the Information Model, still retain the Primary master replica type, even if the requirements document has dropped it.

One fine point, though - I don't know how to represent nor manage a scenario where DIFFERENT DATA are "owned" by different PRIMARY MASTER replicas in the same replication area...I know how to deal and manage having a single replica designated as the primary of all the masters, but not how to tag ownership of specific schema elements.  

So, the information model places the replica type designation on the replicaSubentry, and only one replica of the replication area is deemed to be the "primary master" of the replication context.

Ed

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

>>> "Steven Legg" <[email protected]> 12/06/01 02:35AM >>>


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.

> 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.
>
> 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. Off the top of my head I can't think of anything that is broken
because A and C have the same context prefix but unequal sets of entries
in their naming contexts.

For LDUP we're okay if we say we are replicating "replication contexts"
rather than "naming contexts". C can be said to hold two adjacent
replication
contexts (for subtree X and subtree Y).

>
> I can only find one reasonable way to answer this question,
> it requires each entry to have held by one and only one
> "primary" master DSA and defining the LDUP naming context
> as a subtree of entries held in a single "primary" master
> DSA.  I believe this same solution can be used to define
> other terms and to detail directory models for multi-master
> replication which maps reasonable well onto the X.500 models.

I don't think we need impose this restriction for
what is only a definitional problem.

>
> I recommend the WG consider defining the LDUP multi-master
> replication directory models such that, for any particular
> entry, there is only one "primary" master DSA and zero or
> more "secondary" master DSAs.   Otherwise, defining the
> models consistent with the LDAP/X.500 models will be
> extremely difficult.

Regards,
Steven