RE: naming contexts

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

At 03:06 PM 2001-12-07, Kurt D. Zeilenga wrote:

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