RE: naming contexts

What do you mean "how"?  I'm just not sure what you're
asking the docs to describe - I have been assuming that the
management operations doc would say something like...

"to create a new replication area "B", pick the root of the
subtree that will be partitioned off from the current
replication area "A".  Designate that container entry
as the new replication context root "ou=B", update the
server rootDSE replicationContexts attribute by
adding the name of the new replication context root
to those values already there.  Mark the entry
with something to designate it as an administrative
area root - either via some glue bit in the entry DSE,
or via the addition of an auxilliary class that accomplishes
the same thing.  Proceed by creating a replicaSubentry
directly subordinate to the replication context root for
the local server and set its replica type to "primary" (since
it's updateable, and right now it's the only one, so it's
able to operate as a single-master of the replication area).

Note that other replicas of the replication area "A" will
receive notification that entry "ou=B" is now the root
of a replication area (done via the presence of that
DSE glue stuff or the auxilliary class that was added to
the entry), and the replicaSubentry that designates
which server holds the replica of the new replication
area.  Those other replicas should delete the other
contents of the subtree below "ou=B" (not including
any replicaSubentries), unless they find a replicaSubentry
naming themselves, indicating that they're to hold replicas,
too.  An alternative to this scenario would be that all
replicas of "A" would automatically become replicas of "B",
and any that are no longer needed can be deleted after
the replication topology is fully propagated.

To add another replica of the new replication context, first
add a replicaSubentry for the new server on the replica of 
type "Primary" for replica context "B".  Then, contact
the server that will hold the new replica of "B" and using
some yet-to-be-defined LDAP control, tell it to basically
accept the replication of replica context root "ou=B" and
its replicaSubentry subordinates, which should now include
one pointing to itself.  Then, because the new server update
vector entry is {null, empty, zero, whatever}, both the Primary
replica server and the new replica server should realize that a
full update should be initiated.  That may be done by the
Primary replica, or if some other replica would be better, by
any of the other replicas the new server has just been told
about.  Thus, it probably makes sense for the new server
to pick a replica and request a full update, rather than to
automatically have the Primary initiate it.

Note that no replica that doesn't know about the new
server (ie, that doesn't yet hold a copy of the replicaSubentry
for the new server) should accept a request to provide a
full update to the new server, nor can it begin sending
updates to the new server until it hears about the new
server via receiving the replicaSubentry for the new server.

Also, no server "X" should ACCEPT changes to replica "B" from any server
"Y" that isn't represented in "X"'s set of replicaSubentries for "B".  The
special control mentioned above should provide a specially
access controlled mechanism to "persuade" "X" to receive
the initial replica topology information about a new replica "B"
context from the primary replica of the naming context.  Some
folks may want there to be some action at server "X" to advise it
to expect such a thing, and that's fine - it's just a special
access control thing ("accept it if this has been set already").

Ed

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

>>> "Kurt D. Zeilenga" <[email protected]> 12/07/01 12:28PM >>>

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

At 08:52 AM 2001-12-07, Kurt D. Zeilenga wrote:
>At 09:50 PM 2001-12-06, Steven Legg wrote:
>>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.
>
>Guess I would prefer to violate the latter, not the former.
>
>>Determining naming contexts with respect to a
>>primary satisfies the former but not the latter.
>
>Concur.