Subject: Re: naming context definition

From: "Ed Reed" <[email-masked]>
Date: Sat, 07 Apr 2001 02:55:46 -0600

Yeah - I've wondered what naming contexts are to replication
areas, or replication areas are to naming contexts, once I figured
out what the formal definition of naming contexts was.

The conflict is in the phrase "...and are held in the same master DSA".

X.500(93) is explicitly single master, so there's no way that both
server 1 and 3 in your example could be "master" replicas.

But, of course, we're dealing with multi-master, here, so both
servers 1 and 3 hold a master replica of the A partition of the
DIT, and both servers 2 and 3 hold a master replica of the B
partition of the DIT.  

In this world, I've never appreciated what sense it makes to
talk about server 3 holding a naming context C which is
the union of partitions A and B.  It makes more sense to me
to just say that server 3 holds A and B replication areas.

It strikes me that if there's a conflict, it's likely to be that
you would expect that naming context C would have
subentries that govern the behavior in C, i.e., both
A and B partitions.  

But, we're saying (in the LDAP Subentry draft) that there's
no inheritance...so any subentries you'd want to affect both
A and B need to be separately asserted in each, so that
server 1 and server 2 unambiguously have all their subentry
information without server 2 being dependent on either server
1 or 3 for the DIT partition A subentries.

So, while it may be interesting that server 3 holds
naming context C which is the union of A and B, that information
is of little interest or value to the replication system, or to
clients using the replicaSubentry information to navigate
among servers to answer questions about where what data
are located (ie, to generate referrals or to perform chaining).
Knowing that both server 1 and 3 hold naming contexts rooted
at the same administrative point (A) is nice, but unless you also know
whether the subordinate (b) DIT is also present, you'll just have
to blindly pick one to continue your resolve name operation.  If,
instead, you know that 1 holds A but 3 holds both A and B, then
you may choose to choose server 3 instead of server 1 to
direct your chained or referred operation, since 3 will not have
to refer/chain you again should you need B to answer your query.

Knowledge of where data are can be useful in such cases, and
the more you know about the topology the better informed your
decisions will be (if the operation against A is a single container
or single entry search, then either server 1 or 3 will do, but if
it is an unconstrained subtree search, 3 is by far a better choice).

So - what does LDUP need to do or say?

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <[email-masked]> 04/07/01 12:14AM >>>
X.501(93), Section 17, excerpts:
  naming context: A subtree of entries held in a single master DSA.

  A naming context is a subtree of the DIT, all entries of which
    have a common administrative authority and are held in the same
    master DSA.

  Note: The DIT is therefore partitioned into disjoint naming
    contexts, each under the administrative authority of a single
    master DSA.

It seem to me that the definition of namingContext makes
little sense in the face of multiple master replication.

Consider the following:

A DIT which consists of two adjacent subtrees of entries A and
B where A is superior to B.  C refers to the set of entries
comprising A and B.  Three servers configured as follows: 

Server 1: masters A
Server 2: masters B
Server 3: masters C

Does the DIT consist of one or two naming contexts?

There is no right or wrong answer here... but there is need
for the LDUP specification to provide an answer.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 07 Apr 2001 08:27:34 -0700

>out what the formal definition of naming contexts was.

Well, what I've been trying to figure out is who is authoritative
over an entry (or attribute?).  Naming contexts are just one
part of the administrative model which is based on the simple
premise that each entry is wholly mastered by one and only one
DSA and the administrator of that DSA is authoritative for
each entry mastered in it.

LDUP seems to allow shared authority of an entry and might
even allow authority for certain attributes to different
than for other attributes of an entry (due to multiple-master
fractional replication).  It seems possible that no DSA is
actually required to master all attributes of an entry.

It seems many of the concepts of which LDUP is based upon
just cannot be described using LDAP/X.500 terminology.  That
is, it seems quite difficult to describe a system supporting
multiple-master replication using models designed for
single-master.

>So - what does LDUP need to do or say?

Well, I think the group needs to slash a few requirements.
First, I'd eliminate multiple-master fractional replication.
Then, I'd start examining the question "who is authoritative
over an entry?" because until you answer this, you cannot
design the administrative model.

Kurt

---

From: Jim Willeke <[email-masked]>
Date: Sun, 08 Apr 2001 09:14:11 -0400

If I could pop some ideas into this discussion.

I see no reason for there to be a "Master" of any data, as long as the 
schema is the same across the entries.
Many conflict resolution ideas could be used to replicate the values of 
existing schema entries. (Attributes or Objects). NDS uses a unique time 
stamp and ActiveDirectory uses a GUID stamp and I am sure there are others.
For replication of Schema, I think there must be a "Master" or at least 
an agreement point. You could do somting like:
Change is initiated by server A.
He sends notice (Status Flag perhaps) to the Schema Master (SM).
SM sends notice to all servers in the replication domain that a chenge 
is in progress.
Each Server then notifies SM that they are aware a change is taking place.
Server SM sends the change to all server in the replication Domain.
All servers in the replication domain acknowlege they have received the 
change and they can make the change.
When the SM receives the notification from all server in the replication 
domain, he then send a notice to committ the changes.
Each server then sends notification the change was applied.
When the SM receive notice from all servers in the replication domain, 
the replication domain is unlocked.

-jim