Re: [ldapext] A more radical approach to 2307

["Bannister, Mark" <[e-mail]>]

Andrew Findlay wrote:
> The big value of LDAP and related things in complex organisations is that it allows a single
> abstract representation of 'important stuff' that can be used by many systems.

I would question your use of 'single' and 'abstract'.  That's not how I see directories being used
in complex organisations.

> To work in this environment the systems have to be flexible, with minimal built-in assumptions
> about the data.

It sounds like you're describing a utopian system, but that in itself is an invalid assumption.

> We have already established that no abstract representation can provide the full
> generality and semantics of each system's native database so compromise and simplification
> is essential.

Not necessarily, as not everything needs to interoperate.  Even when it does it's not hard
to have two pieces of information maintained to support the semantics of two different
systems.  Bear in mind that the data in a directory usually comes from and is managed
by an external application.  I don't know any large enterprises where humans edit data
directly within the directory.  Therefore as long as the application that is managing the
entries can be taught that in some cases it needs to maintain a couple of different flavours,
then I see no issue to be solved here.  In the human mind it is "cleaner" to have one
attribute serve all, but if it is simpler all-round to have two attributes instead, the computer
doesn't care, only the human mind seeking a false sense of perfection.

> With this in mind (and donning my best flameproof suit) I suggest a radical approach to the task in hand:
> 
> 	Throw out most of the 2307 NIS-like definitions.
> 
> 	Consider what an Enterprise-level LDAP service might really
> 	contain *before* any OS-specific or app-specific requirements
> 	are imposed on it.
> 
> 	Create new schema if needed to support a clean representation
> 	of that Enterprise data.
> 
> 	Create new AUXILIARY classes to support the attributes needed
> 	for POSIX systems.

In complex systems, it's so much *easier* for us humans to think about throwing away and
starting again from scratch, thinking that the next one will be better.  I see it all too often.
But I rarely see a better product at the end of the process, because what people term as
"legacy" or label as "20 year old code" (by which they infer bit-rot) is actually wisdom,
many lessons learned, greater interoperability.

What you would end up with if you took the "radical approach" is another IPv6, by which
I mean a new standard that was supposed to be better all-round but because it was not
backwards compatible and was too painful for people to easily migrate to still today it is
barely adopted.  Worse, the standards community were then so focused on IPv6 that
IPv4 (on which the largest majority of the internet-connected world still cared) was
getting little or no attention.  That was a mistake.

The promise of something brand new is often more exciting to humans than the thought
of improving something that has been developed and improved by iteration over the
years.  I think, however, that if standards are supposed to reflect what people are
doing now, to take the best of the common approaches and come up with something that
people can actually immediately make use of with very little change to their working
practices, the "radical approach" is not in our calling.  I think we would better serve
those who need these standards by staying focused on incremental improvements,
benefits that can be quickly and easily realised, immediate compatibility with today's
common approaches.

Compare this with the building infrastructure in the world's largest and oldest cities.
We live with it.  We extend it.  Some infrastructure we will never be able to fully
replace, and in many places we don't even try to.  It's too costly, it's too disruptive.
You can try to build a brand new city somewhere else in the country with all new
modern standards, but you won't get that many people moving their homes to
live there.

Mark.



--------------------------------------------------------------------------------

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.