RE: Naming of ACLs, Replication etc

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Whilst I appreciate stephens direction - I am absolutely against dealing
with directory systems as "a set of protocols" - its like trying to with
designing a car but only address the design of the doors.

This will,as it has with LDAP, end up with a pile of disjoined,
fragmented, unscaleable, highly configured set of bits thats a mess.
Problems with data transparency and labels, etc, etc Extension after
extension, now transactions with out a notion of resource locking, now
synchronisation without a notion of time or sync mechanisms.

This may be a choice for some vendors to adopt this approach to object
oriented information systems and go to market that way - but one cannot
design  obvject oriented scaleable distributed database standards from
an access or communications perspective (IMHO).

How on earth can you put into LDAP extensions which read access control
when that is not defined. How does one deal with certficate paths and
using attribute name values which point  into other contexts.

If the desire to invent "lightweight" protocol - and leave all sorts of
system and scaling issues unresolved because that is too hard - perhaps
there wil be a few companies out there that see such work as risky.


At the end of the day its up to vendors and customers and the market -
But I do tend to think customers want turn key scaleable systems based
on interoperable standards - not fragments of specification that lack
the very substance that make things work as a business system.

I also find it odd that giving a "protocol" yet another name like LMMRP
then solves the sync and transaction problems?? It will just be a set of
fields without any notion of the information services that it is
supporting.


It is easy to write a few pages for a new protocol and hype the name -
its not so easy to write scaleable system design documents that the
industry can follow..


I tend to think the market is now using LDAP as the simple access to
X.500 core technology - just so we can have distributed information
directory systems that works.

regards alan




> -----Original Message-----
> From:	Steve Kille [SMTP:S.Kille@isode.com]
> Sent:	Thursday, April 30, 1998 10:14 PM
> To:	ietf-ldapext@netscape.com
> Subject:	Naming of ACLs, Replication etc
> 
> There has been quite a bit of discussions about LDAP ACLs and LDAP
> Replication.
> 
> One of the nice things about LDAP (LD Access Protocol) is that it has
> allowed a clean client/server protocol, which allows a range of
> clients to connect to different systems with LDAP front ends.  
> 
> Access Control and Replication are system functions, which are needed
> to build a distributed directory.   It seems to me that locking single
> mechanisms for access control and replication onto this flexible
> access protocol is a bad idea.  To me, this point has been emphasised
> by the discussion which is looking at how this access control will
> relate to ACAP/IMAP/WebDav.   
> 
> What I would like to suggest is that we restrict LDAP to being a
> directory access protocol, and all agree to do this.   Extensions,
> which are really extensions to this access protocol, can be called
> this (e.g., LDAP Paged Results).  
> 
> However, system extensions, which are not directly tied into LDAP
> should be called something else.  For example "Lightweight MultiMaster
> Directory Replication Protocol (LMMDRP)".   Note that it would be
> possible to build a directory which maintained replicas using LMMDRP,
> which could be accessed by X.500 DAP and NDS, but not by LDAP.   
> 
> I think that this decoupling about how we refer to these
> specifications will help general clear thinking as this work develops.
> 
> 
> Steve Kille