Subject: [ldapext] draft-zeilenga-ldap-dontusecopy-00.txt

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 23 Jun 2005 13:25:47 -0600

I'm struggling to understand what is meant by the terms "copy" and "authoritative". I don't see one as the antithesis of the other.
 
How is a "copy" distinguished from an "original"? 
How does the term "copy" relate to the term "shadow"?
How do these terms relate to the term "read-only"?
 
To me, the term "authoritative" is completely orthogonal to most of this. While an authoritative entry is probably never read-only, the determination of the placement of an authoritative entry may be completely arbitrary or application specific. For example, an address book application may consider a group of entries held on DSA1 to be authoritative, while a provisioning application may consider many of those same entries to be authoritative only when accessed on another DSA. Other applications may wish to share the notion of where an entry is said to be authoritative.
 
In my experience, the need for a control which specifies an operation take place on the authoritative copy typically has to do with update operations. One DSA is said to be authoritative for an entry,  and thus update operations may be asked to be directed at that authoritative copy. This is obviously especially true in multi-master systems.
 
If this is what the I-D seeks to provide, I suggest it rename the control to "useAuthoritative", and allow it to be applied to all operations (rather than interrogation only). The problem is in defining how to determine whether a given entry is authoritative.
 
If, on the other hand, it seeks to force an interrogation operation to be directed to a non-read-only, or non-shadow copy of an entry, it should not introduce the term "authoritative". Rather it should follow X.500 and replace that word with "non-shadow"

Jim

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 23 Jun 2005 20:45:00 -0700

>I'm struggling to understand what is meant by the terms "copy" and "authoritative". I don't see one as the antithesis of the other.

I am using the term 'authoritative' in the same manner which
X.500(93) uses the term 'original'. I am using the term
'copy' in the same manner as the X.500(93) term 'copy'.

>How is a "copy" distinguished from an "original"?

  Replication in the Directory refers to the existence of
  copies of directory entry information and operational
  information held by DSAs other than the DSA responsible
  for the creation and update of the information. This DSA,
  containing the original information, is called the master
  DSA.
...
  A DSA holding copied information forwards all requests that
  would modify the copy information, and all requests that
  indicate that copy information shall not be used, to the
  master DSA holding the information.

>How does the term "copy" relate to the term "shadow"?

"Shadow" is an adjective that applies to some other term,
such as "copy".  A "shadow copy" is information copied
through shadowing.

>How do these terms relate to the term "read-only"?

In X.500, copies are always read-only.

>To me, the term "authoritative" is completely orthogonal to most of this. While an authoritative entry is probably never read-only, the determination of the placement of an authoritative entry may b…

I'll replace "authoritative" with "original" to align with X.500(93).

>In my experience, the need for a control which specifies an operation take place on the authoritative copy typically has to do with update operations. 

As update operations can never be applied to a copy, there is
no need to have a control which says the update operation must
be applied to the original.

>One DSA is said to be authoritative for an entry,  and thus update operations may be asked to be directed at that authoritative copy. This is obviously especially true in multi-master systems.

In X.500(93), only one DSA can be the master for any particular entry.

>If this is what the I-D seeks to provide, I suggest it rename the control to "useAuthoritative", and allow it to be applied to all operations (rather than interrogation only). The problem is in defi…

not.

>If, on the other hand, it seeks to force an interrogation operation to be directed to a non-read-only, or non-shadow copy of an entry, it should not introduce the term "authoritative". Rather it sho…

Yes.  I will use the term 'original'.

(Of course, X.500 use of the term 'master copy' is confuses
matters.  Which, BTW, is why I introduced the term 'authoritative'.)

Kurt

---

From: Pierangelo Masarati <[email-masked]>
Date: Sat, 25 Jun 2005 15:38:40 +0200

>
>
>  When the control is attached to an LDAP request, the requested
>  operation MUST NOT be performed on copied information.  That is, the
>  requested operation MUST be performed on authoritative information.
>
>  If authoritative information for the target or base object of the
>  operation is not available, the server MUST either return a referral
>  to a server believed to be better able to service the request or
>  return an appropriate result code (e.g., unwillingToPerform).
>

There might be a third option, i.e. "chain" the operation by chasing the 
referral to where the original data is contained.  I think you should 
either specify if this is acceptable, provided that chaining ensures 
that the Don't Use Copy control is propagated along with the chaining 
request, or this must not be performed; if you don't clearly indicate 
this, I would infer that the choice is left to implementors (i.e. I 
would consider "authoritative information available" by means of 
referral chasing if the server is generically configured to chase 
referrals).

p.

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 25 Jun 2005 09:16:49 -0700

At 06:38 AM 6/25/2005, Pierangelo Masarati wrote:

>There might be a third option, i.e. "chain" the operation by chasing the referral to where the original data is contained.

I don't think this document and, in general, other documents
defining LDAP control extensions, should mention chaining.  LDAP is
a client/server protocol.  If a server "chains" a request, it
MUST do so in a manner that provides service consistent with
the service model.   This document says what service the
client expects.

>I think you should either specify if this is acceptable, provided that chaining ensures that the Don't Use Copy control is propagated along with the chaining request, or this must not be performed;

I note that chaining servers have some obligation to ensure
that a non-critical control (of any type) is either used in
performing the entire operation or not used in performing the
entire operation.  The chaining server cannot allow a portion
of the operation to be performed with a control and another
portion not to be.  So, when chaining a request (such as
portions of a subtree search) to other servers, it has to
ensure that it and those other servers, all perform the
same operation.  

It's not good enough to simply propagate a control (of any
type).  To ensure proper service is provided the client
(which is general obligation of the directory service),
the chaining server needs to either make the control
critical so as to force it use by all other servers, or to
remove the control altogether to force it not to be used by 
all other servers.  It must do the former if it used the
control in any way in its performance of the operation.
It must do the latter if it ignored the control in any way
in its performance of the operation.  If it hasn't performed
any of the operation, such as in the case where it chains
an entire request (like when it doesn't hold the baseObject
of a search request), then it has the option of including
the control as presented by the client.

(I note that above implies a chaining service based upon
simple rewriting of requests.  Such a service may not be able
to adequately chain all operations.  Generally, one needs to
use a chaining operation which provides the original request
as well information necessary to ensure consistent performance.)

Note that none of this is specific to this control.  Same applies
to all controls.  And, because the semantics are shared, it's
better this be placed in a common document about chaining.

It is appropriate for control specifications to simply detail
what the service is to be provided to the client is.  Whether the
directory service is distributed or not, the receiving server
is obligated to provide service consistent with the service
model.

The document, I believe, adequately specifies what service is
to be provided to the client.