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

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Thanks john - some comments -
I am sad about snipping my icl stuff - I was proud of that. :-)

> -----Original Message-----
> From:	John Merrells [SMTP:merrells@xxxxxxxxxxxx]
> Sent:	Wednesday, April 22, 1998 9:54 AM
> To:	Alan Lloyd
> Cc:	'Uppili Srinivasan'; owner-ietf-ldup@xxxxxxx; ietf-ldup@xxxxxxx
> Subject:	Re: Comments on ldup-replica-req-00.txt
> 
> Alan Lloyd wrote:
> 
> > [snip...icl anecdote]
> 
> >         And I shudder to think that every time an attribute is
> updated,
> > I would have to broadcast over [to] the replicated system,  the DN,
> the
> > attribute type.value and its tag so that it could be verified and
> > possibly superceded by a clash from one or more other places.
> 
> Each operation will require a different set of items to be
> transferredbetween servers. They'll always be a Unique Identifier for
> the entry,
> this is more likely to be a UUID than a DN.  If it's a modify, as you
> suggest, then the attribute identifier and value must be sent.  The
> final piece of information required will be something to aid the
> conflict detection and resolution policy you decide to deploy.
> 
	The mechanism of stating UIDs, DNs (where names are modified)
and such things are easy to say and write down in an RFC - now what.
operationally it will hit walls and system robustness will be demaned
from high end directory systems that run banks, telephone
infrastructures, CAs and online services and military applications.

	As said the image that a directory is a mail address book that
must be replicated is still out there - and some simple tagging system
may be all thats needed for these - 

	If directories are to be a disciplined, robust infrastucture we
really have to watch tagging and transaction mechanisms - If one cannot
scale it and inteconnect it reliably - dont bother.

> >         what about time zones, transit delays, system clock
> resolution.
> 
> You don't have to use time in your conflict detection and
> resolutionpolicy.  You could choose something else.  Like the
> attribute versioning
> which we've just mentioned.
> 
	and what happens if a DSA has a clock set to tomorow and its
updated at the same time - differently -  in the actual time + - a
second,  as a  DSA with its clock set to today ?

	In the ICL system we had to update the system wide clock by 2
microseconds (over the fiber optic to all nodes ) every time a system
resource was updated to ensure that one transaction could only occur at
one time and be reliable - icl again - sorry.

	X.500 permits inconsistencies for this reason - ie clock
synchronisation over the planet is hard - therefore a requirement to
grab the "logical master entry" is provided in the protocol options.


	Can I mention here that one big issue emerging on this planet is
telephone number mobility and internet QOS  and dynamic service
provisioning - both will need very fast operation rate distributed DSAs
to work in an Intellegent Network infrastructure. In addition
distributed domain based access controls will be fundamental. 
	So the replication process really does not want to impose
exponential loads on this infrastructure just trying to keep every thing
consistent.


	regards alan

> >         Distributed - high performance DSAs seem a lot less effort
> and
> > less problematic -
> 
> Lovely, but customers are asking for replicated directory services.
> 
	yes we know,  but that IMHO is because the "directory" experts
have been  preaching that due to products distributed operations too
well or at all (LDAP) and the LDAP theme of doing replication now.  But
then reality hits,  as it always does - scaleability and interopration
and information consistency are now comming to the fore.

	Its going to be an interesting world when all the "replicate
hypers" suddenly realise that all they are doing is casting a system
which is unscaleable by nature and when they want to eventually
interconnect for distributed operations - what a mess they will be in.

	Distribution gets the naming and the knowledge and domain based
access control policies in place (and the distributed performance issues
resolved) that enable directory system scaling. Replication just
provides one with a "copy" of the inteconnection and performance
problems as described that have not been fixed.

	 regards alan

> John
> 
> 
> 
> >         I wonder who can supply those :-)
> >
> >         regards alan
> > > -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: ATT00115.ATT >>  << Message: Re: Comments on
> > > ldup-replica-req-00.txt >>
> 
> 
> 
> --
> John Merrells
> Netscape Communications
> Directory Server
> Software Engineer
> 
> http://people.netscape.com/merrells
>