RE: naming contexts

["Steven Legg" <steven.legg@xxxxxxxxxxxxx>]

Kurt,

Kurt D. Zeilenga wrote:
> At 05:24 PM 2001-12-06, Steven Legg wrote:
> >Kurt D. Zeilenga wrote:
> >> RFC 2256, 5.2.1. namingContexts
> >>    The values of this attribute correspond to naming contexts
> >>    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." ?
> 
> 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.

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.

> 
> 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).
> 
> >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 ?
> 
> Well, that could be argued.

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

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

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