Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <dbis@proseconsulting.co.uk> Mon, 06 January 2014 21:00 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 665F81AE14D for <ldapext@ietfa.amsl.com>; Mon, 6 Jan 2014 13:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 X70zuYfS676M for <ldapext@ietfa.amsl.com>; Mon, 6 Jan 2014 13:00:28 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 386D01AE146 for <ldapext@ietf.org>; Mon, 6 Jan 2014 13:00:27 -0800 (PST)
Received: from host86-182-221-59.range86-182.btcentralplus.com ([86.182.221.59] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1W0HHV-00066B-Pr; Mon, 06 Jan 2014 21:00:18 +0000
Message-ID: <52CB194D.3090009@proseconsulting.co.uk>
Date: Mon, 06 Jan 2014 20:59:57 +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: Howard Chu <hyc@highlandsun.com>, ldapext@ietf.org
References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com>
In-Reply-To: <52CAEA7D.5030002@highlandsun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 06 Jan 2014 21:00:31 -0000

On 06/01/2014 17:40, Howard Chu wrote:
> Mark R Bannister wrote:
>> In August this year, I submitted some new IETF drafts with the intent
>> that they would replace NIS and RFC2307.  It introduces Directory Based
>> Information Services (DBIS).
>> <snip>
> Yes, this is the correct list.

First, Howard let me apologise up-front for not approaching you about 
this sooner.  I appreciate, as the editor of RFC2307bis-02 that it must 
come as quite a shock to you to see a new set of Internet Drafts 
released that could be seen as a direct challenge to your work, and I 
quite understand your defensive posture.  However, I launched this 
initiative as a direct result of working with large corporations (mainly 
banks) who were using RFC2307 extensively across big Linux and Solaris 
installations (between 10,000 to 40,000 hosts) and facing numerous 
pain-points which needed to be addressed.  It was purely technically 
motivated, and I did not mean to cause any offence.  I am completely 
open to ideas and suggestions to further improve DBIS, and I think if 
you dig deep into these drafts and ask me detailed questions you'll 
realise that a lot of time and thought has gone into every decision I 
have made thus far, including preserving whatever makes sense to 
preserve from the RFC2307 heritage.

>
> I must say I'm alarmed at seeing a new proposal that is primarily 
> based on NIS-compatible attribute values. This is exactly the same 
> fundamental problem in the original RFC2307 which made it less than 
> useful for non-Solaris-based OSs like AIX and HPUX. This is the same 
> flaw that I attempted to correct in my updated draft 
> http://tools.ietf.org/html/draft-howard-rfc2307bis-02

Please would you give me some specific examples of what you believe is 
less than useful for AIX and HP-UX, and how you corrected these in 
RFC2307bis-02.  Forgive me but I am coming from a Linux and Solaris 
perspective.

>
> If you're going to all the trouble of storing data into a universally 
> accessible distributed database, you must store it in a canonical 
> format, not a particular OS-specific format as NIS/RFC2307 did.

Please give me some specific examples of attributes which I am storing 
in an OS-specific format.  I am struggling to think of any, so some 
examples will help me understand your point better.

>
> A lot of the data elements and behaviors that the DBIS spec defines 
> appear to be client-implementation-specific details. It seems to me 
> their definition is inappropriate in (outside the scope of) a 
> universally accessible distributed data context.

Again, examples would help you make your point, and help me to 
understand it.

>
> The discussion of caching here 
> http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such 
> example - this is purely a client-side implementation issue. Also you 
> give nscd as an example, and nscd has been thoroughly discredited and 
> is well known to be unsuitable for real use. Critical deployments can 
> use a local LDAP server with a replica of the central data, to avoid 
> error-prone caching implementations. This is a commonly recommended 
> approach when using OpenLDAP nssov, for example.

That's why it's in a section titled "Implementation Notes", i.e. notes 
to help those implementing DBIS.  It's not core to the draft, it's just 
some helpful notes to make the point that the domain-level TTL must 
override any local settings.  I don't see that as such a big deal.  Am I 
missing something?

>
> I agree that this area of spec needs to be polished up, but not by 
> disregarding all of the work that was done and experience that has 
> been gained since the original RFC2307 was published.

Yes, this is why I suspect I may be causing offence, for which I 
apologise.  If you believe I am disregarding all of the work that was 
done on RFC2307 and RFC2307bis, this is not true.  When writing DBIS I 
spent much of my time reading RFC2307 and RFC2307bis, ensuring that I 
had thought about everything, and that I could sensibly preserve 
whatever I could from those documents, because I did not wish to 
reinvent the wheel.  However, some of the fundamental incompatibilities 
with NIS, and some of the flexibility and modularity required in a 
successor, mandated (at least in my mind) splitting it out into a number 
of separate drafts and providing a framework to makes it easy for others 
in the future to define additional maps as and when required.

I did actually begin by thinking, shall I just expand on RFC2307bis?  
But I'm sorry to say this, I found the document too unwieldy and 
inflexible to add much value to it.

I hope you do not feel resentful and perhaps would consider offering 
some more constructive guidance on the development of DBIS.

Best regards,
Mark Bannister.

e: dbis@proseconsulting.co.uk