[ldapext] A more radical approach to 2307

Andrew Findlay <andrew.findlay@skills-1st.co.uk> Fri, 04 December 2015 18:00 UTC

Return-Path: <andrew.findlay@skills-1st.co.uk>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15081A9063 for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 10:00:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcPDcVebDfe1 for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 10:00:12 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C154D1A908E for <ldapext@ietf.org>; Fri, 4 Dec 2015 10:00:07 -0800 (PST)
Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4ueL-0007hF-3k for ldapext@ietf.org; Fri, 04 Dec 2015 18:00:05 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4ueJ-0002gX-Rk for ldapext@ietf.org; Fri, 04 Dec 2015 18:00:03 +0000
Date: Fri, 04 Dec 2015 18:00:03 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: ldapext@ietf.org
Message-ID: <20151204180003.GK3643@slab.skills-1st.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/C2cV1GZXrnj2zYQqU76WAQLftTg>
Subject: [ldapext] A more radical approach to 2307
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2015 18:00:14 -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     |
-----------------------------------------------------------------------