RE: RE: Architecure Draft [Dont Use Copy]

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

One needs to "record the unit of replication" in DSAs.
The unit of replication ( a replicated naming context) may reside in a
DSA with master entries of other naming contexts and both types of
contexts need to be identified. A User may request Master entries only
starting from the high parts of the DIT. In addition if the DSA has
knowledge of other master contexts that can be accessed via DSP, then a
distributed search to those DSAs can be actioned (if such naming
contexts are within the scope of the search)..

Note: X.500 uses knowledge and DSP to retrieve master entries in a
distributed env, if the originating DSA holds a replica and dont use
copy is set.
Note LDAP does not have DSP and leaves the onus on the client to
understand the knowledge/distribution  and information management policy
of any targeted set of LDAP servers.
Note that a LDAP client who wishes to authenticate across a set of
master or replicated LDAP servers, must also have their entry replicated
and the password manageable. And managing password will cause
replication actions to occur.


In working with directory systems  where the requirement is to have
guaranteed access to master information, eg.  Call Record Data,
Targetting information, Stock exchange info.. the facility of "Dont Use
Copy" is deemed essential.

Hope this helps

regards alan
> -----Original Message-----
> From:	Sukanta Ganguly [SMTP:SGANGULY@xxxxxxxxxx]
> Sent:	Saturday, 22 August 1998 2:22
> To:	merrells@xxxxxxxxxxxx; ED#032#REED@xxxxxxxxxx;
> Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx; Lloyd@xxxxxxxxxxxxxxxxxxxx
> Cc:	ietf-ldup@xxxxxxx
> Subject:	Re: RE: Architecure Draft [Dont Use Copy]
> 
> Hi,
>    Does that mean the LDAP Server needs to store the information about
> the copy/replica as some attribute value. First of all why would this
> be an issue at all. If it pertains to replication then the replication
> unit decides what needs to be replicated and the source and target of
> the replication. Why would one need to store information specific to
> particular attributes breaking down the concept of replication unit
> per se. I don't see this being a problem even in the transaction
> operation.
> 
> Sukanta Ganguly
> 
> >>> "Ed Reed" <ED#032#REED@xxxxxxxxxx> 08/21 9:10 AM >>>
> Alan - you are, of course, correct.  A Resolve Name operation which 
> does this is certainly indicated as another possible extended
> operation
> for LDAP, which I hope we will get to as we add "full" distributed
> behavior to LDAP services and clients.
> 
> Ed
> 
> -------------------
> Ed Reed, Technologist
> Novell, Inc.
> +1 801 861 3320
> 
> >>> Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx> 08/20/1998 19:14:12
> >>>
> John - this means more human configuration and more code for the
> client
> software... than X.500 systems
> regards alan
> 
> > -----Original Message-----
> > From:	John Merrells [SMTP:merrells@xxxxxxxxxxxx] 
> > Sent:	Monday, 10 August 1998 9:09
> > To:	Alan Lloyd
> > Cc:	'LDUP '
> > Subject:	Re: Architecure Draft [Dont Use Copy]
> > 
> > 
> > 
> > Alan Lloyd wrote:
> > 
> > > In x.500 entries can be selected as a copy/replica through the use
> > of
> > > Dont Use Copy in DAP and this is carried in DSP. This means that
> > entries
> > > in the DIT need a notion of master or copy indicators.
> > 
> > Our current thinking is that this bahaviour is up to clients to
> > implement.
> > Information about the LDAP servers hosting the Naming Context is
> > published in sub-entries below the Naming Context. A client that
> > demands high consistency would discover the access point for the
> > Primary Replica and apply all its operations there.
> > 
> > John
>