RE: Supported RFC's and "features"

["Clowser, Jeff (Contractor)" <jeff_clowser@fanniemae.com>]

>From: Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] 
>Are you interested in non-RFC features in OpenLDAP that Sun does not
>have?  First you say yes, then no.
>
>Also, are you interested in clients?  The library?  Otherwise don't say
>just "OpenLDAP", since that's both server, libraries and clients.  (I
>don't know which of those, if any, "Sun DS" refers to.)

Sorry - I'm focusing on the server (slapd).  I'm also interested,
eventually, in all the server features, but if I listed all the OpenLDAP
features, this email would be longer than it already is :).  I figure I
can look through all the admin guides, man pages, etc for new (to us)
features openldap has, and until I do that and have more specific
questions, I'd just be wasting bandwidth by doing so.

At this stage, I'm looking for what RFCs it supports, since that's an
easy checklist and allows for easy matching against other choices. 

I'm also looking to feature match the Sun directory server (since that's
what it would be replacing). I need to know that it either supports a
given feature Sun supports, or that it doesn't and we have to determine
how important lack of said function is to us.

>> The following additional RFC's are supported in OpenLDAP:
>> - RFC 2247 and RFC 3088
>> - RFC 4524 COSINE schema
>
>Note that if you find some LDAP implementation which doesn't already
>provide them, supporting these is trivial - just load the schemas
>defined in the RFCs.  Unless the server defines some conflicting schema
>elements of its own.

Yeah - I only listed them because they were listed in the OpenLDAP
faq-o-matic list of supported RFCs.  There are a bunch of other schema
related RFC's that I didn't include because all the ldap servers support
schema extensions.

>> (There are some other, often obscure, LDAP related RFC's that I
didn't
>> include, but this seems to be the major/useful ones)
>
>You may need to compare RFC 4513 features (Authentication Methods and
>Security Mechanisms) in more detail.  E.g. SASL is *defined* as just a
>framework.  Access controls are important, but the details are left to
>the implementation.  So are the details for how to store, hash and
>protect passwords and certificates, how to map between SASL identities
>and LDAP identities (DNs), and various security policies.

Agreed.  Our current usage is mostly simple binds, so from a feature
matching perspective, I'm not too worried.  Once we whittle down our
server software choices to a handful, we can start looking at some of
the "new" benefits we can make use of in a given server, and at that
point we may start looking at actually using additional mechanisms.
(i.e. We have to support current usage, and new functionality comes
second)

> Documentation, support and user community are other "features" you
might
> have a look at.  If you are in trouble, is the doc good enough to get
> you out of it?  Do you get help?  If you opt for paid support, what do
> you get for your money?  (For OpenLDAP, the doc has been lagging
behind
> the software but has steadily improved.  It got a major boost for
> OpenLDAP 2.4.  Paid support - see home page.)

Again, agreed, but that's for another stage of the eval :).  Right now,
my main concern is matching up our choices to what we currently have to
cover current usage (and knowing if a potential choice will not support
something we rely on, so we can determine if it rules out that choice or
to see if we can work around it).  As for documentation, community,
etc... I've been using the Sun DS - 'nuff said there.

 - Jeff