Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <> Mon, 06 January 2014 21:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 665F81AE14D for <>; Mon, 6 Jan 2014 13:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X70zuYfS676M for <>; Mon, 6 Jan 2014 13:00:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 386D01AE146 for <>; Mon, 6 Jan 2014 13:00:27 -0800 (PST)
Received: from ([] helo=[]) by with esmtpa (Exim 4.71) (envelope-from <>) id 1W0HHV-00066B-Pr; Mon, 06 Jan 2014 21:00:18 +0000
Message-ID: <>
Date: Mon, 06 Jan 2014 20:59:57 +0000
From: Mark R Bannister <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Howard Chu <>,
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Subject: Re: [ldapext] DBIS - new IETF drafts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jan 2014 21:00:31 -0000

On 06/01/2014 17:40, Howard Chu wrote:
> 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).
>> <snip>
> Yes, this is the correct list.

First, Howard let me apologise up-front for not approaching you about 
this sooner.  I appreciate, as the editor of RFC2307bis-02 that it must 
come as quite a shock to you to see a new set of Internet Drafts 
released that could be seen as a direct challenge to your work, and I 
quite understand your defensive posture.  However, I launched this 
initiative as a direct result of working with large corporations (mainly 
banks) who were using RFC2307 extensively across big Linux and Solaris 
installations (between 10,000 to 40,000 hosts) and facing numerous 
pain-points which needed to be addressed.  It was purely technically 
motivated, and I did not mean to cause any offence.  I am completely 
open to ideas and suggestions to further improve DBIS, and I think if 
you dig deep into these drafts and ask me detailed questions you'll 
realise that a lot of time and thought has gone into every decision I 
have made thus far, including preserving whatever makes sense to 
preserve from the RFC2307 heritage.

> 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 

Please would you give me some specific examples of what you believe is 
less than useful for AIX and HP-UX, and how you corrected these in 
RFC2307bis-02.  Forgive me but I am coming from a Linux and Solaris 

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

Please give me some specific examples of attributes which I am storing 
in an OS-specific format.  I am struggling to think of any, so some 
examples will help me understand your point better.

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

Again, examples would help you make your point, and help me to 
understand it.

> The discussion of caching here 
> 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.

That's why it's in a section titled "Implementation Notes", i.e. notes 
to help those implementing DBIS.  It's not core to the draft, it's just 
some helpful notes to make the point that the domain-level TTL must 
override any local settings.  I don't see that as such a big deal.  Am I 
missing something?

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

Yes, this is why I suspect I may be causing offence, for which I 
apologise.  If you believe I am disregarding all of the work that was 
done on RFC2307 and RFC2307bis, this is not true.  When writing DBIS I 
spent much of my time reading RFC2307 and RFC2307bis, ensuring that I 
had thought about everything, and that I could sensibly preserve 
whatever I could from those documents, because I did not wish to 
reinvent the wheel.  However, some of the fundamental incompatibilities 
with NIS, and some of the flexibility and modularity required in a 
successor, mandated (at least in my mind) splitting it out into a number 
of separate drafts and providing a framework to makes it easy for others 
in the future to define additional maps as and when required.

I did actually begin by thinking, shall I just expand on RFC2307bis?  
But I'm sorry to say this, I found the document too unwieldy and 
inflexible to add much value to it.

I hope you do not feel resentful and perhaps would consider offering 
some more constructive guidance on the development of DBIS.

Best regards,
Mark Bannister.