[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Naming of ACLs, Replication etc



Steve, I welcome your views and support them in principle  and wish to
add some comment.

> -----Original Message-----
> From:	Steve Kille [SMTP:S.Kille@isode.com]
> Sent:	Thursday, May 07, 1998 9:14 PM
> To:	Alan Lloyd
> Cc:	'James R. Cutler'; ietf-ldapext@netscape.com; Daryl Horsfall
> Subject:	Re: Naming of ACLs, Replication etc 
> 
> Following some of the points made by Alan Lloyd, and the requests for
> clarification from Dave Boreham,  I thought it would be useful to try
> to restate the core point of my original message.  
> 
> I can see three broad "camps" on how directory services should be
> deployed (with various intermediate and combined views).
> 
> 1) X.500 is the way to build a distributed directory.   Most in this
> camp believe that LDAP is also a good thing and a useful way to
> provide access into an X.500 directory (some believe that it would be
> better to have only DAP, but do accept the reality of LDAP access).
> 
	Yes - this view is on the increase and in the process many are
recognising all the deficiencies of LDAP.


> 2) That a distributed directory should be built with LDAP only, and
> that all the missing pieces should be defined as a part of LDAP.  This
> camp generally views that X.500 is a dinosaur, and want to see it
> replaced with a full set of Internet directory specifications.
> 
	However, my view and those of many others dealing with
directories just see that directories will end up an absolute mess if
dealt with under the LDAP banner.
	Simply because one cannot design a distributed object oriented
information system as a set of protocols. That approach defies
information engineering principles for starters as well as making
something which is fundamental to global information systems, fragile.

	To be absolutely blunt here, I think that those writing LDAP
things- specifically areas that deal with eg. access controls and
authentication processes and information integrity and management should
demonstrate that their respective organisations are prepared to
commercialise such contributions. Eg. The LDAP ACL document demonstrates
that a "paper" can be passed into the LDAP work - that is unusable and
totally unfit for purpose. But given the  hype machine that surround
things these days, such contributions can get labelled as the "solution"
. 

	I dont mind these contributions by the way. Because if they are
worse than X.500, then they can be dealt with technical comparisons -
and in terms of product marketing they become an advantage to X.500. eg.
The X.500 suppliers can say .. "X.500 in terms of system integrity, has
a much higer capability of authentication and access controls across a
distributed environment than the LDAP technologies"..So why trust your
corporate information to "lightweight access controls"... ie. Security
which is Simple to implement , by definition is simple to attack.

	I also think that those who think that X.500 is a dinosaur -
should qualify why - in engineering terms. The days of saying OSI and
ASN.1 is slow, dead and too complex is over. (The world is not flat
anymore). OSI is used as the distributed system framework in about every
technology I deal with including On Board Equipment in Cars, Trains and
Buses, ASN.1 is used as the tool to define and implement distributed
systems and their information and protocols. ie there other
international standards groups that apply modern approaches.
	The point here is that the means by which larger systems are
being designed has evolved from the RFC/string based
protocol/trivial-simple-light approaches. If one uses old tools and
approaches - one ends up with old products!
	Also one cannot cure a complex problem with a simple solution -
global distributed directories is a complex problem - (for some :-)) ) 

	I respect the view that  people would like to see X.500 replaced
- but can they stand up and give good engineering reasons why - and HOW
and with WHAT.
	Perhaps such views should say how one can build a distributed,
object oriented, globally applied, name based transaction system with
replication, access controls, binary, image and text capabilities any
differently. Directory systems are a serious technical and commercial
business now..  Their development has passed the noise, ideals and
religion phases.

	If some thing is better than X.500 for directories, can we state
it in objective terms , speed to market, tools required to build it,
features, functions and benefit, how trust and security is applied,
etc..

> 3) That a distributed directory should be built with (their)
> commercial proprietary products.   LDAP will be used for access.
> Replication protocols should be used for (low quality)
> synchronization, but not as a replacement for their (high quality)
> proprietary replication.  Those on this camp, tend to speak in line
> with camp 2, as they oppose X.500.
> 
	If they see a market in proprietary directories that is their
choice. However, most customers I know dont want these any more.
	Opposition is good if it can deliver something better.


> There is a common view in all of these groups that LDAP AS AN ACCESS
> PROTOCOL is a good thing (or at least is something that is a market
> reality).
> 
> My proposal was that LDAP should be used to refer only to the access
> protocol, and (typically optional) protocol extensions directly
> associated with this access protocol.  It seems to me that there is
> convergence on LDAP, and we should be working to make LDAP something
> that all players will want to support.
> 
	The unfortunate aspect of LDAP is that it has removed all the
bits that deal with information transparency, efficient navigation in a
multi server environment, cannot deal with distributed (chaining
control) or replicated (copy/master) selection and relies on the LDAP
configuration army.

	In addition when one tries to build a real directory system with
distribution and certificate path processing, etc, etc  LDAP as a system
just falls to bits.

	I still believe that LDAP is like the wooden wheel on a 747 -
ie. The wheel is alright on its own, but try using it in a operational
environment where one wants utility, reliability and scale.
	 
> There is going to be a real fight over the choice of replication
> protocols and access control mechanisms to be deployed. 
> 
	Thats fine - its those who want to invest in these areas will
fight the hardest. Perhaps we can start the challenge.

	I think that X.500 with its information management model and its
authentication (X.509) with its access controls is the best system for
protecting distributed directory services.

	I thnk that DISP and the way X.500 deals with replicated/master
data in DAP and DSP is the best way of dealing with replicated
information across a distributed directory system.

	Any one got any better ways of doing this?

>    
> 
> I think that LDAP is a wonderful thing, and want to support it.  
> 
	We support it as access and server integration  - the wonderful
bit is OK if it is used with X.500 .

> I think that the access control specified by X.500 is by far the best
> way forward for a directory accessed by LDAP.  Others want to specify
> different mechanisms, and it is clear from recent discussions that
> there are a number of possible alternate ways forward.
> 
> Given the divergence,  I do not think that it is possible or desirable
> to have short term convergence on one mechanism.   I believe that we
> will see multiple specifications and that the market will decide.
> 
> A large market clearly wants to have "LDAP Directories", meaning a
> directory service accessed by LDAP.   
> 
> I think that it will be perjorative to have one of the specifications
> for access control called "LDAP Access Control".   Rather,  I think
> that the various proposals should have names which do not include the
> name "LDAP".
> 
	Got my vote..



> We should reserve LDAP for the access protocol which we all believe
> in, and not use it for new specifications which will be very
> contraversial.   
> 
	Ditto

	regards alan

> Steve Kille
>