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

Mark R Bannister <dbis@proseconsulting.co.uk> Sun, 01 February 2015 22:33 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 AF5E31A1B71 for <ldapext@ietfa.amsl.com>; Sun, 1 Feb 2015 14:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 LQCF0QP9p44o for <ldapext@ietfa.amsl.com>; Sun, 1 Feb 2015 14:33:15 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id C22F31A1B6C for <ldapext@ietf.org>; Sun, 1 Feb 2015 14:33:14 -0800 (PST)
Received: from host86-178-119-20.range86-178.btcentralplus.com ([86.178.119.20] helo=[192.168.1.67]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1YI34q-0000yK-No; Sun, 01 Feb 2015 22:33:13 +0000
Message-ID: <54CEA9A4.1020709@proseconsulting.co.uk>
Date: Sun, 01 Feb 2015 22:33:08 +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: Simo <s@ssimo.org>
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <1422454472.32747.38.camel@ssimo.org>
In-Reply-To: <1422454472.32747.38.camel@ssimo.org>
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/fNVSH2gwBFMPZ9PO2GV_Af_VPow>
Cc: ldapext@ietf.org, =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>
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: 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
>> 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.
> 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 
improvements
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,
Mark.