RE: Comments on ldup-replica-req-00.txt

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From:	Uppili Srinivasan [SMTP:USRINIVA@xxxxxxxxxxxxx]
> Sent:	Wednesday, April 22, 1998 1:08 PM
> To:	alan.lloyd@xxxxxxxxxxxxxxxxxxxx
> Cc:	ietf-ldup@xxxxxxx
> Subject:	RE: Comments on ldup-replica-req-00.txt
> 
> Alan wrote:
> 
> > Yes I would love to but that would take years 
> >  [snip .. anecdote]
> >
> I am glad you tried nevertheless! :-)
> 
> >	Distributed - high performance DSAs seem a lot less effort and
> > less problematic - 
> > [snip .. product pitch]
> 
> You are comparing apples to oranges. 
> 
	No I am not. - sorry I do have experience with distributed and
replicated systems AND there is always a requirement in online business
level transaction - replicated systems, the need to get at the master
entry - just in case - in most finacial and military applications some
replicated inconsistencies may be accommodated, but in the real sharp
end of the business they are not.

>  It is like arguing (point to point)
> ftp is better than (store and forward) e-mail.  This group *is*
> discussing
> directory distribution, but through *replication*. 
> 
	Please dont confuse the two terms - Distribution in directory
parlance is processing of transactions in a distributed namespace -
distributed means there is a protocol such as DSP that does loop
detection and can build fractional responses from the servers it talks
to.
	Replication is the copying of one names space from one server to
another. Quite a different meaning.

	X.518 is about Distribution - DSP
	X.525 is about Replication - DISP

>  There are so many
> different kinds of customers and their requirements are not all the
> same. 
> Many trust that replication is the most effective and reliable for
> their
> deployment needs.  
	Agree - but given the first point above re master entry
requirements - then Distribution must always be there as well
particularly if WANs and batch updates are involved.

> (Yes, I *am* talking about customers with requirements
> for 10000000000000000000 entries and 1000000000000 concurrent users
> etc.  I
> didn't count all the zeroes :-)
> 
	Thats good - can we have their names and contact details :-)

> Could we focus on the requirements and quickly come to a resolution on
> what
> are the acceptable boundaries for discussions.
> 
	Agree - lets get to basics - 
	One cannot do replication without the notion of a namespace -
ie. an administrative area and possible refinements within that. Thats
what replication agreements are made of.
	One cannot do Access Control without the notion of an
administered  namespace  ie.  an AC administrative area with overarching
policies and possible refinements of that.
	One cannot do distribution without the notion of interconnected
administrative areas.

	TOP LEVEL
	Now in replication we have master and replicated data.
	WE also want to identify which data is master and which is copy.
	We want User access protocol and services that let us select
that.

	System level
	Replication agreements which are managed 

	Protocol level
	Protocol for the Negotiation of agreements
	Protocol for the Transfer of replicas - robust - transaction
based atomic - see DISP


	Information level
	 - tags/uids, flags, time stamps, etc - dont standardise this -
implementation dependent - unscaleable.


	I think that first and formost - the LDAP work should deal with
administrative areas - because replication and access control will have
no shape without them.
	X.500  defined its management model in the X.500 1993 release
(operational atttrs and admin areas) just so it could solidify its
replication/distribution and access control designs.

	Perhaps LDAP has arrived at the same point.

	So what do peope want to design first.

	regards alan

> Thanks!
> -Uppili Srinivasan 
> ______________________________________________________________________
> ______ 
> Oracle Corporation |  
> Box 659510         |Phone: (650)506-3039   Internet:
> usriniva@xxxxxxxxxxxxx
>  
> 500 Oracle Pkwy    |Fax:   (650)506-7122  
> Redwood Shores     |X.400: c=us; a=telemail; p=oracle; o=oragate;
> s=usriniva
>  
> CA 94065           |  
> ___________________|__________________________________________________
> ______
>  
>   
>  
> 
>  << File: ATT00128.ATT >>