> Specifically, in looking how the NAC is proposing a conformity test which
> will effectively give vendors a base line stamp of approval for their
> LDAP implementation, I must ask the question, What will this baseline
> test prove? If the lowest common denominator for interoperability means
> that an LDAP client from one vendor can access an LDAP server from
> another vendor, does that really fulfil the promise of the spec?

Absolutely. That is precisely the key promise made by having a vendor-OS-independent, vendor-hardware-independent, open, *network protocol* specification. I.e. this is just basic LDAP "motherhood and apple pie" stuff.

So, testing and demonstrating base-line multi-vendor interoperability on a highly heterogeneous network is quite interesting.

> I understand that many vendors are choosing to implement LDAP extensions
> above this baseline as a means to a competitive advantage, but who is to
> say that those will work with other implementations?

Well, no one. But, "interoperation" in terms of something as complex as an extensible directory protocol, such as LDAP, has a large potential solution space. Here's an example that I hope will help clairfy this..

If you have a client from one vendor that implements the core ldap protocol plus some (sub)set of the documented protocol extensions (see below), and a server from another vendor implementing the core ldap protocol plus it own particular (sub)set of the documented protocol extensions, then..

And so testing these assertions is a resonable and interesting thing to do. For any given pair of client and server, one would hope that the first two assertions are true and the last is false. But only conclusive way to know is to actually do hands-on, active testing.

On one hand, such testing will benefit vendors by actively uncovering implementation and interoperability bugs, and on the other it will benefit customer orgs by..

This is quite important because, for example, the directory service providers at an organization may well not have any control over the set of clients users will use (that's our situation here at stanford). Users at many orgs are going to be able to simply download most anything off the Internet and give it a go. In this sort of case it is imperative for the service providers to be able to decide on a given server vendor, and thus a service feature profile, independent to some extent of the clients users acquire. Having knowledge of the results of interoperability testing is invaluable in this situation. It aids directory service providers in making a set of statements in their service profile such as..

> Which extensions do you think are appropriate to undergo interoperability
> testing ...

Well, ideally all implemented ldap protocol extensions ought to receive multi-vendor client/server interoperability testing.

Specifically, a directory service provider will want to have done (and/or have hard evidence that it was done) testing sufficient to make whatever claims they make in their service profile.

> ... in order that the end users will be able to get real benefits
> from the LDAP-enabled products that they buy.

I believe the core protocol functionality is such that end users will likely see a definite benefit from clients that at least properly implement that level of functionality. I say "likely", tho, because the actual utility delivered to the user via the directory service (i.e. the union of the clients and the server(s)) rides at least as much on the quality of the information placed in the target directory, and the quality of the organization of that info, as it is on the quality of the client and server implementations.

I hope this helps answer your questions. Even tho LDAP is "Lightweight" (i.e. compared to the X.500 protocol standards & implementations), directory services, and thus LDAP, are inherently complex.

I.E. there's no accurate short answers. 8^)

A clarification about LDAP protocol "extensions"...

There are two legit flavors of "extensions" a given client and/or server implementation may incorporate..

  1. legitimate (i.e. defined via IETF process) ldap *protocol* extensions. 
     e.g see...
draft-ietf-asid-ldapv3ext-04.txt draft-ietf-asid-ldapv3-sorting-00.txt draft-ietf-asid-ldapv3-tls-01.txt draft-ietf-asid-ldapv3-simple-paged-01.txt draft-ietf-asid-ldapv3-strong-00.txt   2. vendor-specific client and/or server *implementation features* e.g...   - which particular (sub)set of authentication capabilities are implemented.   - what sort of authorization capabilities are implemented. Note that authorization (as opposed to authentication) conventions and capabilities are not defined in the ldap protocol spec and thus are left entirely up to vendors to design and implement. See below for brief explanation of authentication vs. authorization.   - what sort of server and directory-content creation, configuration, and adminstration features are implemented, and also what sort of client configuration capabilities are impl'd. (these are non-trivial aspects of vendor differentiation).

..and one clearly "illegit" (from an "openness" perspective), and one "grey-area" case..

  3. An illegit ldap protocol extension would be some material change to the 
     protocol itself (e.g. defining a new protocol operation) that is not 
     defined in terms of the protocol extension capability that is an intregal 
     part of the ldap protocol spec, and that is not openly documented and 
     incorporated in the specs via the IETF process.
  4. A grey-area ldap protocol extension would be one that is implemented via 
     the legit extension mechanisms defined in the ldap specs, but that is not 
     openly documented via the IETF process. 

Colloquial definition of "authentication" and "authorization"...

Authentication and authorization are orthogonal, but related concepts. First, 
two parties authenticate, and then they decide what each is authorized to do...
  authentication ::= "I (the client) am who I say I am, please validate 
                      it via these credentials."
                           plus, perhaps...
                     "And I (the server) am who I say I am, here's my 
  authorization ::= "ok, so I (the server) now knows who this requestor is, 
                     and I have info specifying what operations 
                     it may specifically perform on any given 
                     entry and/or attribute. So, I'll let it go for it, 
                     and let it know if it oversteps its bounds."