Re: [ldapext] DBIS - new IETF drafts

Howard Chu <hyc@highlandsun.com> Mon, 06 January 2014 17:40 UTC

Return-Path: <hyc@highlandsun.com>
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 D10721AE12E for <ldapext@ietfa.amsl.com>; Mon, 6 Jan 2014 09:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level:
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 6gK8Nhy7HSsj for <ldapext@ietfa.amsl.com>; Mon, 6 Jan 2014 09:40:24 -0800 (PST)
Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 547121AE136 for <ldapext@ietf.org>; Mon, 6 Jan 2014 09:40:23 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 58EF910F3D; Mon, 6 Jan 2014 12:40:14 -0500 (EST)
Message-ID: <52CAEA7D.5030002@highlandsun.com>
Date: Mon, 06 Jan 2014 09:40:13 -0800
From: Howard Chu <hyc@highlandsun.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1
MIME-Version: 1.0
To: Mark R Bannister <dbis@proseconsulting.co.uk>, ldapext@ietf.org
References: <52C9BED5.2080900@proseconsulting.co.uk>
In-Reply-To: <52C9BED5.2080900@proseconsulting.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [ldapext] DBIS - new IETF drafts
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: <http://www.ietf.org/mail-archive/web/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: Mon, 06 Jan 2014 17:40:27 -0000

Mark R Bannister wrote:
> In August this year, I submitted some new IETF drafts with the intent
> that they would replace NIS and RFC2307.  It introduces Directory Based
> Information Services (DBIS).
>
> Michael Ströder suggested I post a link to this mailing list.  The
> following article (and further articles on my blog) discuss some of the
> aspects of DBIS, and link to all of the relevant internet drafts:
> http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html
>
> I am currently working on a reference implementation here:
>       http://sourceforge.net/projects/dbis/
>
> This may be coming out of the blue for many of you, and I appreciate you
> may need some time to read and digest my drafts, and then ask me lots of
> questions.
>
> But my first question to you is, where is the best place for discussion
> related to these drafts?  Is this the mailing list to use?

Yes, this is the correct list.

I must say I'm alarmed at seeing a new proposal that is primarily based on 
NIS-compatible attribute values. This is exactly the same fundamental problem 
in the original RFC2307 which made it less than useful for non-Solaris-based 
OSs like AIX and HPUX. This is the same flaw that I attempted to correct in my 
updated draft http://tools.ietf.org/html/draft-howard-rfc2307bis-02

If you're going to all the trouble of storing data into a universally 
accessible distributed database, you must store it in a canonical format, not 
a particular OS-specific format as NIS/RFC2307 did.

A lot of the data elements and behaviors that the DBIS spec defines appear to 
be client-implementation-specific details. It seems to me their definition is 
inappropriate in (outside the scope of) a universally accessible distributed 
data context.

The discussion of caching here 
http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example 
- this is purely a client-side implementation issue. Also you give nscd as an 
example, and nscd has been thoroughly discredited and is well known to be 
unsuitable for real use. Critical deployments can use a local LDAP server with 
a replica of the central data, to avoid error-prone caching implementations. 
This is a commonly recommended approach when using OpenLDAP nssov, for example.

I agree that this area of spec needs to be polished up, but not by 
disregarding all of the work that was done and experience that has been gained 
since the original RFC2307 was published.


> Best regards,
> Mark Bannister.
>
> e: dbis@proseconsulting.co.uk
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/