Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <dbis@proseconsulting.co.uk> Fri, 10 January 2014 13:47 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 A1EA71AE020 for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 05:47:01 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 G6sU5GnzFjEB for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 05:47:00 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A21ADEBE for <ldapext@ietf.org>; Fri, 10 Jan 2014 05:46:59 -0800 (PST)
Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1W1cQC-00033V-Ld; Fri, 10 Jan 2014 13:46:48 +0000
Message-ID: <52CFF9B0.6020408@proseconsulting.co.uk>
Date: Fri, 10 Jan 2014 13:46:24 +0000
From: Mark R Bannister <dbis@proseconsulting.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Michael Ströder <michael@stroeder.com>, ldapext@ietf.org
References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <52CB194D.3090009@proseconsulting.co.uk> <52CB1DE3.6040000@highlandsun.com> <52CB2194.30907@proseconsulting.co.uk> <52CB26C6.1070406@highlandsun.com> <52CDB3FC.2000205@proseconsulting.co.uk> <52CEB72F.9050000@stroeder.com>
In-Reply-To: <52CEB72F.9050000@stroeder.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Subject: Re: [ldapext] DBIS - new IETF drafts
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: Fri, 10 Jan 2014 13:47:01 -0000

On 09/01/2014 14:50, Michael Ströder wrote:
> Mark R Bannister wrote:
>> I don't personally like the idea
>> of having per-user shadow attributes, however some might see it as a feature
>> and there may be some edge cases where this is exactly what is required.
> AFAICS today nobody is seriously using LDAP with shadow attributes anymore.

Please provide me some empirical evidence that this assertion is true.

>
>> draft-behera-ldap-password-policy-10 is already widely deployed, you say?
>> Then it must go higher up in my reading list.
> Yes, it's the only standard considered widely deployed. You have to know it.

Thanks.  Do we have any idea how widely adopted it is?

>
>> Indeed, I agree, as stated earlier on I would whole-heartedly recommend
>> against having user-specific policy settings.  However, providing the facility
>> as an option for those who want to make minimal changes to their NIS
>> environment is harmless.
> If I replace NIS with LDAP I already have two options:
> 1. Simply use RFC 2307(bis) for a naive transition
> 2. Do a migration to really meaningful LDAP schema
>
> IMHO with 2. I can drop all NIS specific things anyway. You have to decide
> whether DBIS is just an improvement for 1. or a real innvotation for 2.

It's 2.  Show me something I've done that's not "really meaningful" and 
we'll look at improving it.

Best regards,
Mark.