Re: [ldapext] DBIS - new IETF drafts

[Mark R Bannister <[e-mail]>]

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: [e-mail]