Subject: [ldapext] A more radical approach to 2307

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 18:00:03 +0000

RFC2307, 2307bis and DBIS all start from the NIS/YP/files-in-etc model
and represent the data in LDAP with varying degrees of fidelity.
Is this actually a good idea? I rather think not.

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. To work in this environment the
systems have to be flexible, with minimal built-in assumptions about the
data. 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.

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.

The resulting set of attributes and classes would be *much* smaller than
the 2307 set. Some whole categories could just vanish, e.g.:

	All the shadow password stuff (draft-behera is difficult enough
	and we don't need to duplicate its function on the client side)

	memberUid (we really *dont* need a POSIX-specific way to
	represent groups, and the syntax of memberUid does not even
	match that of uid)

	Most of the less-used NIS-map attributes and classes could be
	hived off into separate documents, or even dumped in favour of a
	generic structural lookup table with explicit case ignore/case
	sensitive semantics.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

---

From: Jim Willeke <[email-masked]>
Date: Fri, 4 Dec 2015 10:10:03 -0800

I tend to agree with Andrew.

--
-jim
Jim Willeke

On Fri, Dec 4, 2015 at 10:00 AM, Andrew Findlay <
[email-masked]> wrote:

> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext
>

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 21:09:48 +0100

> Is this actually a good idea? I rather think not.

Yepp. RFC 2307bis should be splitted.

> 	and we don't need to duplicate its function on the client side)

Yes, 'shadowAccount' is already regarded deprecated.

> 	represent groups, and the syntax of memberUid does not even

That's the only thing we might want to consider to keep because of
backwards-compability to existing client implementations.

> 	generic structural lookup table with explicit case ignore/case

It might be worth to preserve some of the stuff but really in a separate generic
document.

Ciao, Michael.

---

From: "Bannister, Mark" <[email-masked]>
Date: Fri, 4 Dec 2015 22:39:06 +0000

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:
> 

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.

---

From: Jordan Brown <[email-masked]>
Date: Fri, 4 Dec 2015 16:06:16 -0800

On 12/4/2015 2:39 PM, Bannister, Mark wrote:
> [ start from scratch, vs incrementally improve ]

Both answers are right, and both answers are wrong.

It's wrong to throw away an architecture when it largely works, just needs a 
little tweaking, and where a replacement would be essentially the same.

It's also wrong to slavishly preserve a legacy architecture when it's clearly 
flawed and a replacement could be better and cleaner.

Both errors happen all the time.

I tend to think that what we have here is a mix of the two.