Subject: RE: no-copy control requirement

From: "Ed Reed" <[email-masked]>
Date: Tue, 10 Apr 2001 07:37:18 -0600

Steve - sounds like a good approach, to me.  This also sounds like a control
definition that needs to be defined...but where?  doesn't make sense to 
do it in the mandatory to implement management operations doc, nor
the info model.

Perhaps it's time to create a single LDAP control that embodies the
common arguments that are otherwise missing from X.500 DAP?  That
way they'd be there syntactally, whether actually in use or not, and
the groundwork would be made for promoting LDAP to DAP in the
long run (just had to throw that it - its starting to make sense to me).

Whachathink?

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Steven Legg" <[email-masked]> 04/09/01 10:29PM >>>

Ed,

In X.500 single master replication an entry is either a master (modifiable)
copy or a shadow (read-only) copy. For every shadow entry there is a
corresponding master entry, transient inconsistency notwithstanding.
In our current multimaster architecture an entry is either a shadow copy,
a co-mastered copy or a single-mastered copy. There is either one
single-mastered copy of an entry within the replica group or two or more
co-mastered copies. If we use a no-copy *bit* then we have to decide
whether it means don't use shadow entries or don't use shadow or
co-mastered entries. If it means the latter then an operation should be
failed if no-copy is requested but the entry is co-mastered.

If one master replica is nominated as some sort of primary then we have
four possible entry copy states: shadow, co-mastered, primary-co-mastered
or single-mastered. An entry can have both co-mastered copies and a
primary-co-mastered copy within the replica group.

A two-valued control isn't enough. We would want clients to be able to
request one of the four following treatments through a control.

1) Use any kind of copy. This case doesn't apply for updates.

2) Don't use shadow copies (use any mastered copy). This case should be
the default when the control is absent. I'm inclined to map the X.500
dontUseCopy service control to this case as well. This control setting
won't cause an operation to fail.

3) Don't use shadow or co-mastered copies (use primary-co-mastered or
single-mastered copies). The operation should be failed if there is
no primary-co-mastered or single-mastered copy.

4) Don't use shadow or co-mastered or primary-co-mastered copies
(use only single-mastered copies). The operation should be failed
if there is no single-mastered copy.

If the control is expressive enough then we don't need to *mandate* the
existence of a primary master replica. Clients decide if it matters to
them whether a primary master replica is actually deployed.

For good measure we can also add a fifth case to the control:

5) Guarantee strong consistency. If the entry is single-mastered then
strong consistency is already assured, but if the entry is co-mastered
the control implies the client is requesting that a distributed update
be invoked - something like the locking solution John McGarvey is
talking about, or the strong consistency solution I sketched out previously
on the mailing list.

Regards,
Steven

Ed Reed wrote:
> And, this would require either
> 
> 1) reinstatement of the "primary" replica designation, as the "owner"
> of all data in the replication area (not the same as the server to
> which all data modifications are made, but a "soft" designation for
> use by applications, like replica topology management, to use
> by common agreement as the single server to use so that such a
> "high confidence" or "no copy" bit can be made to make sense), or
> 
> 2) carry sufficient information on each attribute value so that the
> server where that data was originally entered into the DIT can be
> identified (the CSN replica id may suffice), so that the client (or
> chaining or referring server) can individually contact each of the
> servers at which various values of attributes for the entry was
> entered and verify that the values read at the copy are still
> the values of record at the originating server.
> 
> Of course, in a multi master environment, there's no guarantee
> that #2 above will actually contact a server where an update
> has occurred that has not yet propagated to either the DSA
> handling the no-copy request from the client (presuming it is
> either chaining or that it is trying hard to provide useful
> referral information to the client), or indeed to the DSA where
> the original value was entered.  
> 
> Using the approach in #1, it is possible for applications with
> single-master dependencies to algorithmically select a single
> master of all the master replicas (by looking at the replica types)
> to which to direct their modification operations, without unduely
> hindering other applications that dont' require such relatively
> high assurance consistency.  But it does not give the client
> nor any server the omniscience required to locate as yet un-
> replicated changes among the replicas of the DIT.  
> 
> I don't know of other approaches to providing this non-LDAP
> control, but I agree its a necessary thing to define.  I had
> thought it something to be defined as part of the distributed
> operations model of the directory, instead of the LDUP
> itself.
> 
> It's also interesting to consider how the whole subject of
> referrals and how they're to be generated gathers the information
> to give to the client who wants to constrain itself to talking
> to data where "copy is not sufficient" constraints are in place.  
> Another argument, in my view, of using information in the DIT
> that includes replica type knowlege, as the source of things
> like subordinate references (so references generated
> for clients who have asserted the "no copy" control will be
> correctly directed to the appropriate replica of the subordinate
> name space).
> 
> Ed
> 
> =================
> Ed Reed
> Reed-Matthews, Inc.
> +1 801 796 7065
> http://www.Reed-Matthews.COM 
> 
> >>> "Kurt D. Zeilenga" <[email-masked]> 04/09/01 01:29AM >>>
> X.500 replication model provide a mechanism for clients
> to state the operation should not be preformed on a 
> copy of the entry.  This is useful when the client
> needs to ensure it is operating upon the master DSA
> instead of a shadow DSA.  There likely should be some
> requirement to support this feature in LDUP.
> 
> Kurt
> 
> 
>

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 12 Apr 2001 10:52:49 +1000

Ed,

> do it in the mandatory to implement management operations doc, nor

The control itself deserves its own ID, however some of the model
aspects belong elsewhere. It makes sense to me for the four entry
copy states to be described by the info model, where they can be
referenced by any knowledge/distribution model documents and the
control's specification, among other things.

> common arguments that are otherwise missing from X.500 DAP?

I take it you mean a control for X.500 CommonArguments facilities missing
from LDAP rather than a control for facilities missing from the X.500
CommonArguments. Isn't English wonderfully ambiguous ?

I recall the former being suggested in the past, but not receiving much
support. One difficulty is that extending such a control requires the
involvement and cooperation of the X.500 working group. Such an extension
would be required to handle the richer replica copy selection cases that
arise due to multi-master replication. Anyway, I'm in favour since I
already support CommonArguments for DAP.

> That

Especially now that the X.500 protocols can be implemented over TCP/IP
without the OSI stack.

Regards,
Steven