Subject: naming context definition

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Apr 2001 23:14:03 -0700

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: "Ed Reed" <[email-masked]>
Date: Sat, 07 Apr 2001 09:39:14 -0600

Your point about authoritative "ownership" of entries is a good one.

The original model called for three replica types:  Primary, Updateable,
and Read/Only.  

The Primary was there because I (yes, me) wanted to promote a
single-master replica topology scheme on top of the multi-master
data replication scheme.  That is, the Primary replica is a designated
updateable replica to which all modifications of replicaSubentries
and replicationAgreements would be directed.  I think the restriction
could be reduced to say that Primaries are the only places where
creations, modifications, and deletions of replicaSubentries are allowed.

This effectively makes the mandatory to implement management operations
a single-master application, regardless of how many updateable replicas
there are for the replication area, only the master would permit additions
or changes to replicas.

As I said, that was my original notion.  That's not what we have, now.

The requirements as they are presently written eliminated the primary
replica designation, and renamed the updateable replica type to be "master".
All's equal, none superior, there is no ownership of the name space, anyone
with sufficient administrative authority can add a replica or otherwise
change the replica topology.  Further, there's no way to tell if there
are replica topology changes already propagating through the environment,
because they could have been initiated anywhere.  So race conditions,
naming collisions, and all manner of other multi-master "untidyness"
will bedevil replica management operations.

I think that is unwise.  I don't know how to safely manage the replica
information without a coordinator of the topology.  Others who do will have
to work with the management operations authors to demonstrate how
to do it.

I had forgotten that the primary replica also neatly fills the role of
"data owner" that the X.500 master provided - the primary replica, being
the final authority over what new replicas may be placed on what servers,
effectively "owns" the data in the replication area, and controls where
it may flow.  That is another desireable property of the Primary replica.

I would propose that the Primary replica type be restored to the requirements
document.  It still exists in the architecture model and information model
documents.

Ed

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

>>> "Kurt D. Zeilenga" <[email-masked]> 04/07/01 09:27AM >>>
At 02:55 AM 4/7/01 -0600, Ed Reed wrote:
>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.

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: "Ed Reed" <[email-masked]>
Date: Sun, 08 Apr 2001 17:54:55 -0600

That's very much the kind of distributed operation coordination
that the "primary" that I had in mind to do for replicaSubentries.

Schema is possibly another good application for the same thing -
it would simplify some conflict resolution issues by insisting that
the schema be "unlocked" - i.e., completely distributed to all
replicas - before allowing LDAP operations that depend on it
to change data.

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065

>>> Jim Willeke <[email-masked]> 04/08/01 07:14AM >>>
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