Subject: naming contexts

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 05 Dec 2001 21:24:04 -0800

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.

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.

If C masters X and Y and A and B are shadows,
LDAP/X.500 says that:
	A, B, C holds context X

If A, B, and C master the subtrees they hold, which
contexts does LDUP say they hold?

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

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 6 Dec 2001 18:35:06 +1100

Kurt,

> 	Subtrees X and Y are adjacent.

From what follows, I assume that Y is subordinate to X.

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

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

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

> models consistent with the LDAP/X.500 models will be

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Dec 2001 05:45:10 -0800

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

>portion (subtree Y) of context X.

Yes,
  A,B,C publishes the name of the vertex of X.

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

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

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 7 Dec 2001 11:30:51 +1100

Kurt,

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

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

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

> to choose one.  You appear to choose a), yes?

Yes, and for b) I use replication contexts.

> comprise one naming context on that server.  Yes?

Yes.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Dec 2001 16:46:23 -0800

>has shadow entries. Its namingContexts attribute should be absent.

RFC 2256, 5.2.1. namingContexts
   The values of this attribute correspond to naming contexts
   which this server masters or shadows.

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 7 Dec 2001 12:24:03 +1100

Kurt,

>    which this server masters or shadows.

Of course you mean RFC 2252, but I take the point. I didn't look
beyond the description in RFC 2251 (doh!). However, I wonder if it
should instead say: "The values of this attribute correspond to the context
prefixes of naming contexts which this server masters and the names
of the base entries for replication areas that this server shadows." ?

In X.525, the root of a shadowed subtree doesn't have to correspond
to a context prefix entry. It can be a subordinate of a context prefix.
Perhaps it is more useful to a client to know the topmost shadowed
entry rather than the context prefix ?

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Dec 2001 18:24:47 -0800

>of the base entries for replication areas that this server shadows." ?

Well, the problem is partial replication.  Consider a naming context
containing has N entries where N-1 are immediately subordinate to
context prefix and a replica which holds these N-1 entries (and not
the context prefix).  Your definition would require N-1 namingContext
values.

The LDAP/X.500 models assume that the shadow server has knowledge
as where the context prefix is mastered.  While publishing this
the context prefix may lead the client to believe the shadow server
holds the context prefix, this is a bad assumption.  The value
means that the shadow server holds a portion of the naming context.
This is "good enough" for most uses (the shadow generally has
knowledge to refer the client as needed).

>entry rather than the context prefix ?

Well, that could be argued.  But LDAP/X.500 is the way it is.  I
have no problem with replicaContexts behaving in this manner (though
I believe the partial replication issue applies here as well).

My concern is that LDUP does not define how a server is to
populate namingContext.  I argue it need to be defined in a manner
consistent with LDAP technical specification [including, by reference,
Section 17 of X.500(93)].  I believe the best (only?) way to do this
is to term one of the masters the "primary" in respect to this naming
context information (and, as Ed suggests, portions of replication
management information).

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 7 Dec 2001 16:50:45 +1100

Kurt,

> the context prefix).  Your definition would require N-1 namingContext

It depends on the replication agreements. If there is a separate
replication agreement for each one of the N-1 subordinates then
there will be N-1 namingContext values. If there is a single
replication agreement that happens to exclude the context prefix
entry then there will be only one namingContext value.

> Well, that could be argued.

Yep. That's why I made it a question. :-)

> But LDAP/X.500 is the way it is.  I

I don't believe there is any way we can define multimaster replication
such that we remain 100% consistent with the existing definition
for a naming context. Either we violate the assumption that the DIT
is partititioned into disjoint naming contexts, or we violate the
requirement that the superior of a context prefix entry is in a
different master DSA. Determining naming contexts with respect to a
primary satisfies the former but not the latter.

Introducing the concept of replication contexts provides a disjoint
partitioning of the DIT to use where such is needed while preserving
the constraint that the superior of a context prefix is in a different
master DSA. Servers can work out the naming contexts from the
replication contexts they hold. A naming context is just a bunch
of adjacent mastered replication contexts.

Whether we call fragments of the disjoint partitioning of the DIT
naming contexts or replication contexts, I think the partitioning
can be administered without resorting to a primary replica.

See you in Salt Lake City.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Dec 2001 08:52:34 -0800

At 09:50 PM 2001-12-06, Steven Legg wrote:
>different master DSA.

Guess I would prefer to violate the latter, not the former.

>Determining naming contexts with respect to a

Concur.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Dec 2001 09:28:04 -0800

Replying to my own message to stress one point:

I believe that the LDUP technical specification must define
how replicas are to populate the namingContext attribute in
their root DSE as clearly replicas participating in multi-master
replication cannot do this in accordance with LDAP "core"
technical specification.

Kurt