Re: [ldapext] LDAP work at IETF...

Mark R Bannister <> Sun, 01 February 2015 22:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF5E31A1B71 for <>; Sun, 1 Feb 2015 14:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LQCF0QP9p44o for <>; Sun, 1 Feb 2015 14:33:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C22F31A1B6C for <>; Sun, 1 Feb 2015 14:33:14 -0800 (PST)
Received: from ([] helo=[]) by with esmtpa (Exim 4.71) (envelope-from <>) id 1YI34q-0000yK-No; Sun, 01 Feb 2015 22:33:13 +0000
Message-ID: <>
Date: Sun, 01 Feb 2015 22:33:08 +0000
From: Mark R Bannister <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Simo <>
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Archived-At: <>
Cc:, =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <>
Subject: Re: [ldapext] LDAP work at IETF...
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: Sun, 01 Feb 2015 22:33:17 -0000

On 28/01/2015 14:14, Simo wrote:
> On Tue, 2015-01-27 at 20:50 +0000, Mark R Bannister wrote:
>> On 27/01/2015 15:47, Michael Ströder wrote:
>>> Mark R Bannister wrote:
>>>> The following internet drafts are intended to replace RFC2307 and RFC2307bis.
>>>> [..]
>>>> draft-bannister-dbis-mapping
>>>> draft-bannister-dbis-netgroup
>>>> draft-bannister-dbis-passwd
>>>> draft-bannister-dbis-hosts
>>>> draft-bannister-dbis-devices
>>>> draft-bannister-dbis-automounter
>>>> draft-bannister-dbis-custom
>>>> [..]
>>>> I would prefer to see RFC2307bis removed from the list to be considered above,
>>>> and replaced by the DBIS drafts.
>>> This probably won't happen because there are so many RFC2307(bis) deployments
>>> out there which cannot easily be migrated.
>> DBIS supports maps defined in legacy RFC2307 or RFC2307bis format, as
>> well as using the new format.  Migration is designed to be extremely
>> easy.  In fact, it took me next to no time at all to start using
>> directory entries defined in RFC2307 format from a DBIS installation, it
>> really is just a matter of defining a few configuration maps that do the
>> class and attribute remappings, and they are mostly standard.  See
>>> Also I have my own schema built on top of RFC2307bis (not published yet) which
>>> differs much from DBIS for very good reasons. I aim to present it at LDAPcon
>>> 2015 in Edinburgh (in case the program comittee agrees). A preview version of
>>> that is already in production for almost a year in a large data center.
>>> So my suggestion would be to brush up RFC2307bis as much as possible (taking
>>> care of Kurt's IANA comments) so that you can base DBIS on that, as I will
>>> base my system on top of that.
>>> How does that sound to you?
>>> Ciao, Michael.
>> DBIS is not a superset nor a child schema that inherits from RFC2307bis,
>> nor is it built on top of RFC2307bis - it is a complete replacement and
>> was designed as such.  RFC2307 and RFC2307bis can be completely retired
>> and DBIS put in their place and there would be no omissions.  It's an
>> evolution that began life by taking RFC2307bis and splitting it into
>> logic units (separate internet drafts) that make for a less unwieldy
>> document and make it easier for others to extend.  Then I standardised
>> the client-side configuration, fixed some of the NIS incompatibilities
>> that had been inherited from RFC2307, added a few much needed enterprise
>> features, and that's it: a modern, modular, extensible, enterprise-ready
>> RFC2307bis under another name ("2307bis" wasn't a very friendly name,
>> after all, and I wasn't going to call my improvements "2307ter", but
>> they could have been called that, because realistically that's what they
>> are).
>>> So my suggestion would be to brush up RFC2307bis as much as possible (taking
>>> care of Kurt's IANA comments) so that you can base DBIS on that, as I will
>>> base my system on top of that.
>>> How does that sound to you?
>>> Ciao, Michael.
>> I don't see a reason to try to improve RFC2307bis, I think that would be
>> a backwards step.  The improvements needed to RFC2307bis have already
>> been made, I've done the work myself and named it "DBIS" because I
>> couldn't wait for everyone else to catch-up, and I needed it last year
>> :-)  I think if people started looking deeper into the DBIS internet
>> drafts, making suggestions for improvement etc. we'd get to a much
>> better end point than if you have people pore over RFC2307bis again.
> It hurts me to curb enthusiasm, but I think your drafts are not a step
> forward, at most a step sideways, and ignore what's out there right now.

Given that they were written to fix specific deficiencies in RFC2307bis 
that were causing
pain in a number of very large enterprises I have worked for, I don't 
see how they
could be considered a step sideways.

When you say my drafts ignore what's out there right now, what are they 
ignoring?  I
don't quite understand that point.  I'm very open to make changes that 
would make
the drafts more useful in other organisations too, but I cannot make 
when faced with generic statements that have no detail behind them.

> The software out there and now expect either RFC2307 or at most
> RFC2307bis (and then really they just test against Active Directory's
> schema and things happen to mostly work). Any other schema would just
> fail to be useful for a generic LDAP server.
> Simo.
To what software do you refer specifically?  NSS is a big subscriber, 
and I've addressed
that one.  Then there is the automounter, and sudo, and really only a 
handful of
others all of which can be fixed to use a more modern schema.

I'm not going to spend 18 months developing DBIS to be turned away 
because software
doesn't support it.  Of course software doesn't support it - yet - it's new!

Best regards,