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

Mark R Bannister <dbis@proseconsulting.co.uk> Tue, 27 January 2015 20:51 UTC

Return-Path: <dbis@proseconsulting.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 9922A1A8AC3 for <ldapext@ietfa.amsl.com>; Tue, 27 Jan 2015 12:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.299
X-Spam-Level:
X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3] autolearn=no
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 sMvna-7EBS0E for <ldapext@ietfa.amsl.com>; Tue, 27 Jan 2015 12:51:03 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id B3F831A8AAE for <ldapext@ietf.org>; Tue, 27 Jan 2015 12:51:02 -0800 (PST)
Received: from host86-178-119-20.range86-178.btcentralplus.com ([86.178.119.20] helo=[192.168.1.67]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1YGD6D-0004UJ-1i; Tue, 27 Jan 2015 20:51:01 +0000
Message-ID: <54C7FA23.7000101@proseconsulting.co.uk>
Date: Tue, 27 Jan 2015 20:50:43 +0000
From: Mark R Bannister <dbis@proseconsulting.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>, ldapext@ietf.org
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com>
In-Reply-To: <54C7B32A.7050709@stroeder.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/RRFeIZtDlgt5ZaOsZnxJrRt9twk>
Subject: Re: [ldapext] LDAP work at IETF...
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: Tue, 27 Jan 2015 20:51:05 -0000

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 
https://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/

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

Best regards,
Mark.