RE: naming contexts

No - I meant replica context.

I'll confess that when I started on LDUP I didn't understand what
naming contexts were, and I frankly thought they were just a list
of all the partitions replicated onto a DSA.  I've since learned
differently, but that confusion led to our initially talking about
naming contexts, and when I finally got it, we changed and
began talking about replication areas and replica contexts.  Some
of the earlier confusion may not have been wrung out of the info
draft, for which I'm sorry.

I'll make a special effort in the next round of doc cleanup to get
the two terms consistently used throughout the docs.

Ed

>>> "Kurt D. Zeilenga" <[email protected]> 12/07/01 06:06PM >>>
At 02:34 PM 2001-12-07, Ed Reed wrote:
>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...

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]

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

Do you mean really mean "naming context" here?