Subject: RE: naming contexts

From: "Ed Reed" <[email-masked]>
Date: Fri, 07 Dec 2001 15:34:35 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Dec 2001 15:06:11 -0800

>management operations doc would say something like...

LDAP [RFC 2251] says "namingContexts: naming contexts held in
the server. Naming contexts are defined in section 17 of X.501 [6]."

This, IMO, provides an adequate technical specification (the
"how") for the namingContexts attribute.

However, as we've discussed on this list, this definition
is inadequate in the face of LDUP multi-master replication.
Hence, LDUP needs to provide an adequate technical specification
(the "how") for the namingContexts attribute.

Currently, the LDUP Architecture seems to define "naming context"
as:
        A Naming Context is a subtree of entries in the
        Directory Information Tree (DIT).  There may be
        multiple Naming Contexts stored on a single server.
        Naming Contexts are defined in section 17 of [X501].

Though the first sentence I find a little misleading as a
Naming Context is a subtree of entries with very particular
properties, the second sentence indicates that the definition
of naming context is that in section 17 of [X501].  The
document then goes on to define "replication contexts".

The Information Model seems to equate a "naming context"
with a "replication context".

> [lots of stuff about how replication areas are created]

>context from the primary replica of the naming context.

Do you mean really mean "naming context" here?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Dec 2001 16:12:02 -0800

Guess I hit that send button a little early on that last post...

I believe the LDUP Technical Specification needs to say
something like:
        LDAP naming contexts [Section 17 of X.501] are not used
        by LDUP implementations as their definition does not
        address the implications of multi-master replication.

        Implementations of LDUP will populate the namingContext
        attribute with LDUP Foo contexts, not LDAP/X.500
        naming contexts.

        A LDUP Foo context is a ....

Substitute 'Foo' with something appropriate and provide an
adequate definition of what a 'Foo Context' is. 

Kurt