Re: DBIS - new IETF drafts

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).
>
> Michael Ströder suggested I post a link to this mailing list.  The
> following article (and further articles on my blog) discuss some of the
> aspects of DBIS, and link to all of the relevant internet drafts:
> http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html
>
> I am currently working on a reference implementation here:
>       http://sourceforge.net/projects/dbis/
>
> This may be coming out of the blue for many of you, and I appreciate you
> may need some time to read and digest my drafts, and then ask me lots of
> questions.
>
> But my first question to you is, where is the best place for discussion
> related to these drafts?  Is this the mailing list to use?

Yes, this is the correct list.

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

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.

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.

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.

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.


> Best regards,
> Mark Bannister.
>
> e: [email protected]
>
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/