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/
- [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Arthur de Jong
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Ludovic Poitou
- Re: [ldapext] DBIS - new IETF drafts Clément OUDOT
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Charlie
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Neal-Joslin, Robert (3PAR Engineering)
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Charlie
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister