...

I believe that LDAP can be the core of this toolset.

Why not put everything into a MySQL db? :)

Arrgghhh!!! he yells running and screaming in horror... Of all the example products you could have chosen to represent database software, why on earth did you choose this abomination. Is it a dbm-style unordered hash or a B+tree database or an SQL relational database? No, none of the above, it's a stew of pieces hacked from all the above-mentioned carcasses all boiled up in a pressure-cooker until nothing is left but a quick meal. If you had asked, why not use a relational or SQL database, I would have answered thusly. There's nothing wrong with relational databases even those using SQL. However, these are storage systems and I suggested a communications protocol, namely LDAP. If you want to store your directory data in an SQL database and serve it up via LDAP, this can be done with most of the commercial LDAP servers and with openLDAP as well. IBM has done some good work in showing how an LDAP schema can be effectively mapped into an SQL database schema.

LDAP is a fine tool but it was not designed to do some of the things that other tools do.

This applies to SQL/relational databases as well. In fact, LDAP was specifically designed to do things that SQL/relational systems don't do very well. And the set of things that LDAP does maps quite well to things like directories, DNS, whois, rwhois, IRR, RIPEdb, PKI and similar things. More or less, relational systems handle tables well, while LDAP handles hierarchically structured data objects well. In the relational world the focus is on the storage systems and the standards are application programming interfaces like SQL or ODBC. In the LDAP world, the focus is on an efficient and effective communications protocol that can be the frontend to any storage system.

We are not yet at the point where all we have the the LDAP hammer so everything looks like a db-nail.

I beg to differ. We are at the point where there are numerous commercial LDAP servers, where Sun and Microsoft have integrated LDAP into their OS for yp/NIS types of services and where the open-source server has matured and become a credible solution for serving LDAP. Added to this are the large number of LDAP-related tools for browsing, schema design, interfacing, replication/backup etc. And then there are the many books on LDAP and the courses on LDAP and the fact that LDAP knowledge is a basic part of the skillset for certification by Novell, Microsoft, Cisco, Sun, etc. We all do have the LDAP hammer or we can easily rent or buy one. And we can easily find people who know what one is and who know how to use it. Have you ever tried to hire someone with rwhois experience or RADB experience? If so, put out the same ad asking for LDAP experience and note how much larger the pile of resumes is. In the early '90's the Internet community had to invent a lot of protocols and tools to make things work. Today, this is no longer necessary because we can leverage a lot of stuff from the commercial world. The military have discovered the same thing and generally look for COTS solutions before building their own. I'm not saying that we never have to design another protocol, just that we should use more pre-existing work by others in those areas where our needs are not so unique. --Michael Dillon