Re: [ldapext] DBIS - new IETF drafts

Howard Chu <> Mon, 06 January 2014 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E18F91AE27F for <>; Mon, 6 Jan 2014 13:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hQF39nWFe_tu for <>; Mon, 6 Jan 2014 13:57:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BCC351AE27E for <>; Mon, 6 Jan 2014 13:57:36 -0800 (PST)
Received: from [] (localhost []) by (Postfix) with ESMTP id AE55A10F3D; Mon, 6 Jan 2014 16:57:27 -0500 (EST)
Message-ID: <>
Date: Mon, 06 Jan 2014 13:57:26 -0800
From: Howard Chu <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1
MIME-Version: 1.0
To: Mark R Bannister <>,
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ldapext] DBIS - new IETF drafts
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: Mon, 06 Jan 2014 21:57:39 -0000

Mark R Bannister wrote:
> Do you have any more alarming problems that can be turned into simple
> requests?

Just read thru and 
again there's a lot of redundant work here, this time in regards to

The obvious issue is collisions in some attribute descriptors with the ppolicy 
spec, which is already widely deployed.

More problematic is the data model itself, again. Storing the actual policy 
settings in the user entries will be unmanageable for any moderately large 
sized user population. This is one reason why draft-behera uses dedicated 
policy objects. It is the client side DUA's job to adapt the universal data 
store to the local host's security implementation. And we already have 
pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so I don't 
see much value in defining yet another new broken data model that has no 
existing client support.

As much as you claim to have read and absorbed the prior work in this area, it 
really appears that you have ignored most of it.

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP