RE: Naming of ACLs, Replication etc

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

> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Friday, May 01, 1998 9:01 AM
> To:	ietf-ldapext@netscape.com
> Subject:	Re: Naming of ACLs, Replication etc
> 
> Alan Lloyd wrote: 
> 	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.
> 
> You don't need any extensions to the protocol for these functions. 
> Access control information is defined in terms of attributes with 
> values in DIT entries. 
> 
	Yes - X.500 uses subentries and ACI and use standard DAP to
manage them. The standard X.500 Read operation has Modify Rights request
so one can view entry privileges.. But LDAP does not do reads ....

	So why did the draft LDAP ACL document add extensions to the
protocol for ACI or permissions

> Use attribute values which are URLs
> 
	Oh really -- directories are about name based transaction
systems where names relate to people, ships, devices, roles, certificate
issuers, etc...
	 for business use.  This is a fundamental concept which seems to
be missed in LDAP hence no distribution and lots of configuration..

	URLs are related to things in machines (they are machine
references). Directories MUST  (see RFC 2119) RELATE real world named
things to machine named things and in a distributed environment.. If the
LDAP only system directory cannot deal with real named things in a
distributed environment, just highly configured machine named things in
a restricted environment then it does not serve much as a directory...
As said my mum in london does not have a URL stamped on her head.
	I suppose its like hyping up that one is designing a lightweight
car (because real ones are too complex) and then when you go to sell it
you expect everyone to pedal the thing. ie. Do we have to change the way
we want to interwork and get named just because of a desire to invent a
"simple protocol"...!


> point to other contexts. This is the value of a strong and consistent 
> information model (which I think must be what you're calling 
> "object oriented" etc). There are entries with attributes, those have
> values, 
> put your stuff in them, get it back out. Define what you stuff means 
> to yourself and anyone else sharing the information. 
> 
	 See above - its only those who know where it the information is
can access it
	.

> 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).
> 
> There's always an explicit or implicit information model behind any 
> access protocol.
> 
	In object oriented design I think that the Object definition and
the naming/object process (eg ACI) environment in which the objects
reside dictates the protocol.
	But if you come from designing the protocol first - you tend to
end up with a very fractured and unscaleable information model.. 
	ie The ability in DAP (not LDAP) to deal with chaining (or not)
and master/replicated entries (or not) are determined by and processed
within the X.500 system model. These are not in LDAP because it has no
system to work with - QED. it is the system environment of the objects
which dictate the protocol and the referencing attribute types (eg DNs
or URLs).

>  In the case of LDAP, the model is derived from X.500. 
> Your statement about designing the information model from the protocol
> 
> is not applicable to LDAP (or any other protocol I can think of). 
	See above.
> 
> Are you saying that the X.500 information model is flawed in some way
> ? 
> 
	Absolutely not..I think the LDAP development model has proved
that designing information systems from a "protocol perspective" is
absolutely flawed.
	LDAP has ended up twice the code size, half the functionality,
half the information flexibility and twice as slow on the wire as DAP. 
	It still has problems and inconsistencies and leaves one open to
deal with "distribution" access controls, information management - you
know all the things that need to be added to a "protocol" to make a
system and then make a commercially deployable information product.



	
	If so, please tell us so we may use a better one for future LDAP
work.
	See above - There is the basic OO design principles and then
there are the system features of management Access Controls and
Distribution - just follow those .

		I also think the IT industry is getting very aware of
the Lightweight... marketing mis information which in reality is not so
lightweight.
		So I think that if another L------ directory protocol
gets launched a lot of people are likely to throw up. 

		LDAP has enabled many clients to become directory
enabled... thats good.

		LDAP has also proved that all the problems examined and
resolved in DAP and X.500 were real problems and that X.500 has now
solved them.
		X.500 is not complex or slow - its just that it provides
a very powerful directory system for global EC.

> 	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..
> 
> 
> Please post links to your documents so I may follow them. 
> 
	Our mailer seems to do curious things at odd times . ??? 
	regards alan  
>