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

Mark R Bannister <dbis@proseconsulting.co.uk> Tue, 27 January 2015 23:27 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 8EB931A911E for <ldapext@ietfa.amsl.com>; Tue, 27 Jan 2015 15:27:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ld6mvuUzR9Nq for <ldapext@ietfa.amsl.com>; Tue, 27 Jan 2015 15:27:12 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id EBCDD1A9070 for <ldapext@ietf.org>; Tue, 27 Jan 2015 15:27:11 -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 1YGFXK-0001Km-QR; Tue, 27 Jan 2015 23:27:11 +0000
Message-ID: <54C81EBD.3020804@proseconsulting.co.uk>
Date: Tue, 27 Jan 2015 23:26:53 +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: Michael Ströder <michael@stroeder.com>, ldapext@ietf.org
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <54C80DB9.10901@stroeder.com>
In-Reply-To: <54C80DB9.10901@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/NT7Rn3bD9EYsRQfREgCy4WWo-VM>
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 23:27:14 -0000

On 27/01/2015 22:14, Michael Ströder wrote:
> Mark R Bannister wrote:
>> On 27/01/2015 15:47, Michael Ströder wrote:
>>> 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.  [..]  See
>> https://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/
> It seems there was a misunderstanding, probably my wording wasn't clear enough:
> The issue is that many LDAP *clients* are hard-coded to the RFC2307 or
> RFC2307bis schema. The server's data can be IMHO way more easily migrated than
> legacy client systems.

I don't see an issue with that.  Standards move on, old clients become 
legacy, and eventually they have to be weeded out.  Standards would 
never evolve if we could never cut the umbilical cord.  By the same 
token, NIS clients could not use RFC2307 because they were hard-coded to 
use NIS servers.  The latest standards are installed where the latest 
client installations are deployed.

At least DBIS gives you an option to mix old and new schemas.  You could 
start with new clients referring to old-style data.  Then you could 
introduce extra new-style data on the side that is only available to the 
new clients, and eventually phase out the old clients.  That is not an 
option with RFC2307bis.

>
>> DBIS is not a superset nor a child schema that inherits from RFC2307bis, nor
>> is it built on top of RFC2307bis
> Ok, I see.
>
>> RFC2307 and RFC2307bis can be completely retired and DBIS
>> put in their place and there would be no omissions.
> Unfortunately, no.

 From a client perspective, yes.  An RFC2307/RFC2307bis client can be 
converted to a DBIS client using the old-style schema as described 
above.  DBIS simplifies migration.

>
>> I think if people
>> started looking deeper into the DBIS internet drafts,
> I've looked into your drafts. But it differs very much from what I'm after. We
> had this discussion before: IMO netgroups must die, die, die...

This contradicts your earlier assertion that clients are hard-coded.  In 
the same vein, clients are hard-coded to use netgroups, ergo netgroups 
cannot "die, die, die".  Actually a year ago you wrote, and I quote:

"Personally I also avoid netgroups (or I don't have a real use-case for 
them for now)."

... which is a lot more passive than "die, die, die".

Rather than attempting to kill off something that is used extensively, 
and has actually proved to be very useful in large UNIX/Linux estates 
(if a bit clunky), I've embraced them, rationalised them, defined them 
in a neater and queryable format, and complemented them with netservices.

Apart from netgroups, which you are not a fan of, how else does DBIS 
differ from what you're after?  I've made numerous updates to the 
internet drafts in the year since we last exchanged emails about it, 
many of those updates inspired by comments I received then, so what is 
remaining on your wish-list that I did not address?

Best regards,
Mark.