RE: naming contexts

Ed,

Yes, but the explanation in the DRAFT for this attribute is MUCH LESS 
restrictive than what you have been implying.

There are indications that NO Primary replica need exist, it need NOT be 
the same for different replication contexts, and even that MULTIPLE 
primary replicas might exist.  Thus, I have not interpreted the meaning of 
replicaType=Primary to be as "strong" as was implied in earlier postings 
on this thread.

Regards,
Tim Hahn

Internet: [email protected]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681





"Ed Reed" <[email protected]>
12/06/2001 12:15 PM

 
        To:     <[email protected]>, Timothy Hahn/Endicott/IBM@IBMUS
        cc: 
        Subject:        RE: naming contexts

 

Tim - from the currently posted draft...

8.2.8. replicaType 
 
   (2.16.840.1.113719.1.142.4.4 NAME 'replicaType' 
      DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 
            3-ReadOnly, all others reserved' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
      EQUALITY integerMatch 
      SINGLE-VALUE 
      NO-USER-MODIFICATION 
      USAGE dSAOperation ) 
 
   ReplicaType is a simple enumeration, used to identify what kind of 
   replica is being described in a Replica object entry.

It is replicaType 1-Primary that I'm speaking of.

Ed

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

>>> "Timothy Hahn" <[email protected]> 12/06/01 09:42AM >>>
Ed,

In its current state, the information model does not yet contain 
indicators of "primary master".  I believe we are, currently, requiring 
that IF replicaSubentry information is entered at different server 
instances, that it WILL be entered consistently with respect to what was 
entered on the other server instances.  If not, then results are 
indeterminant.  If so, then the two servers will "synchronize".

Either that or we were thinking that the "initial set of replicaSubEntry" 
information would be entered on ONE OF the servers" and then replicated to 

(and so be consistent) with the OTHER servers that were referenced.  The 
idea being that no SINGLE server is noted as "primary master" - just that 
ONE server is used to enter the "initial settings".

This is what I recall anyway,
Tim Hahn

Internet: [email protected] 
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681





"Ed Reed" <[email protected]>
Sent by: [email protected] 
12/06/2001 10:35 AM

 
        To:     <[email protected]>, <[email protected]>, 
<[email protected]>
        cc: 
        Subject:        RE: naming contexts

 


1) I'm pleased to see Kurt referring to a "Primary Master", as I think 
such a concept is needed to represent the single-master of replica 
topology information about a replication context.  However,

2) I agree with Steven that what becomes interesting in a multi-master 
environment is the replication context, not the naming context, held by a 
server.  Frankly, in the mostly-distributed directories I've worked with, 
replication contexts were all that were available, since they're more 
informative about what is actually held, allow clients to piece together a 

minimal set of servers needed to fully traverse a distinguished name when 
searching for a named entry, etc.

But here the interesting point - there IS a place for a "Primary Master" 
when you ABSOLUTELY NEED some data in the DIT to be single-mastered, even 
if the rest of the data can be multi-mastered.  In my example 1 above, 
those data are the operational attributes and subentries associated with 
the definition, description and management of a replication area.

Thus, the Model (Architecture) document and, I think, the Information 
Model, still retain the Primary master replica type, even if the 
requirements document has dropped it.

One fine point, though - I don't know how to represent nor manage a 
scenario where DIFFERENT DATA are "owned" by different PRIMARY MASTER 
replicas in the same replication area...I know how to deal and manage 
having a single replica designated as the primary of all the masters, but 
not how to tag ownership of specific schema elements. 

So, the information model places the replica type designation on the 
replicaSubentry, and only one replica of the replication area is deemed to 

be the "primary master" of the replication context.

Ed

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

>>> "Steven Legg" <[email protected]> 12/06/01 02:35AM >>>


Kurt,

> It seems to me that the definition of a "naming context"
> in LDAP/X.500 makes little sense in the face of multi-master
> replication.  A LDAP/X.500 naming context is subtree of
> entries held in a single master DSA.
>
> Consider three DSAs A, B, C where
>                A masters subtree X
>                B masters subtree Y
>                C masters subtrees X and Y, and
>                Subtrees X and Y are adjacent.

>From what follows, I assume that Y is subordinate to X.

> If A and B are masters and C is a shadow of each,
> LDAP/X.500 says that
>                A holds context X, B holds context Y, and
>                C holds contexts X and Y.

C holds a shadow copy of contexts X and Y.

> If C masters X and Y and A and B are shadows,
> LDAP/X.500 says that:
>                A, B, C holds context X

C holds context X, which is now the union of the subtrees X and Y,
i.e. there is no longer a context Y. A holds a shadow copy of a
portion (subtree X) of context X. B holds a shadow copy of a different
portion (subtree Y) of context X.
>
> If A, B, and C master the subtrees they hold, which
> contexts does LDUP say they hold?

Having an entry mastered by more that one master DSA doesn't invalidate
the definition of naming context as far as I can see, but we do need
to be a bit more careful how we phrase things.

A holds a naming context with the context prefix being the root of the
subtree X. B holds a naming context with the context prefix being the
root of the subtree Y. C holds a naming context with the context prefix
being the root of subtree X, the same root as A but with a superset of the
entries. Off the top of my head I can't think of anything that is broken
because A and C have the same context prefix but unequal sets of entries
in their naming contexts.

For LDUP we're okay if we say we are replicating "replication contexts"
rather than "naming contexts". C can be said to hold two adjacent
replication
contexts (for subtree X and subtree Y).

>
> I can only find one reasonable way to answer this question,
> it requires each entry to have held by one and only one
> "primary" master DSA and defining the LDUP naming context
> as a subtree of entries held in a single "primary" master
> DSA.  I believe this same solution can be used to define
> other terms and to detail directory models for multi-master
> replication which maps reasonable well onto the X.500 models.

I don't think we need impose this restriction for
what is only a definitional problem.

>
> I recommend the WG consider defining the LDUP multi-master
> replication directory models such that, for any particular
> entry, there is only one "primary" master DSA and zero or
> more "secondary" master DSAs.   Otherwise, defining the
> models consistent with the LDAP/X.500 models will be
> extremely difficult.

Regards,
Steven