RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt

[Peter Strong <pestrong@nortelnetworks.com>]

Kurt/Mark

> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Tuesday, February 08, 2000 3:30 PM
> To: Mark Meredith
> Cc: ietf-ldapext
> Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt
>
> Mark, a few comments:
>
> I suggest that this draft be a informational elective feature.

As a designer of products that have to support multiple directory
implementations, I have to disagree. Vendor identification information
should be mandatory in all directory implementations until such time
as vendors get together, solve their differences and make their
directory implementations truely interoperable. (I'm not holding
my breath for this momentous event!)

> I believe that prior operational experience with such features
> have proven to be source of numerous interoperability problems.

I don't think that providing useful information is the source of
interoperability problems.

The source of interoperability problems is the basic fact that vendors
will always implement part or all of a standard in order to say that they
comply and will then add other features/bells/whistles to differentiate
their product from their competitor's. This may cause some clients
difficulties, but it's the way the world works and the way that new
technologies are introduced and (eventually) standardized.

As we progress with directory technology, more and more of the basic
standards are implemented by vendors, but this implementation takes
place at different rates for different vendors. Knowing the vendor
and the version via a "standard" mechanism simply makes it easier
to determine what implementation you're talking to and what
"implementation quirks" might exist. I think Mark makes it clear
that clients shouldn't depend on this information too heavily:

     The use of vendorName and vendorVersion SHOULD NOT be used to
     discover features. It is just an informational attribute. If a
     client relies on a vendorVersion number then that client MUST
     be coded to work with later versions and not just one version and
     no other.

> You'll end up with clients that only support select versions
> of select vendor products and other vendors resorting to
> spoofing the vendor names/versions.  (We've already have
> received requests (and patches) from users to do exactly
> this!).

This is like saying that indicator lights on cars are dangerous because a
driver may signal one way and turn the other; therefore, we shouldn't have
signal lights on cars!

If you're stupid enough to develop a client with hard-coded limits based
on this information, you get what you deserve!

If you have vendors spoofing this information, they'll get what they
deserve - in the marketplace!


All debate aside, this "feature" is simple, straightforward and useful
to those of us who must attempt to integrate our products with multiple
directory implementations.

We're currently faced with delivering product that must interwork with
Netscape, Novell, Active Directory and an in-house directory, with
others on the way. As one example of what we have to deal with, each of
these directories has a subtly different way of altering the schema
definitions (even though there is a standard for this behaviour). We
currently have to perform some really disgusting, poking and prodding to
determine what type of directory we're talking to in order to perform the
schema changes properly. We'd rather just query some attributes at a
well-known location and perform the appropriate schema update based on that
information.

Directory implementations will always have differences. It's that simple.

If we're arguing about such a simple addition on the basis that it may
disrupt the ivory tower of interoperability, I fail to see how far more
complex aspects of directory usage will ever be standardized or agreed to.


> I suggest adding an applicability statement to the overview,
> such as:
>   This document describes an elective feature which LDAP
>   servers MAY implement.
>
> I then suggest that the applicability statement in each
> attribute descriptions be replaced with a technical
> specification.
>   The value of vendorName contains the name of the vendor
>   producing or providing server implementation.
>   Example: "Novell, Inc."
>
> Likewise for vendorVersion:
>   The value of vendorVersion contains the string indicating
>   the version of the directory implementation.
>   Example: "NDS
> 2100-r1.2.3/NT4SP3/US-crypto-128-1.1/TurboBlaster-v2 compat FooDir"
>
> No matching rules are defined.  An EQUALITY
> matching rule should minimally be defined.  I suggest
> caseExactMatch.
>
> Security Considerations:
>
> You may want to add a note publishing specific vendor
> information may be used by clients to determine what
> security holes a server provides (by feature or flaw).
>
> You may note that servers MAY restrict access to
> vendorName/vendorVersion and clients SHOULD NOT
> expect such attribute to be available.
>
>
>

Regards,

  Peter

------------------------------------------------------------------------
Peter Strong
Software Architect
Nortel Networks - Optivity Policy Services (OPS) and NetID
pestrong@nortelnetworks.com <mailto:pestrong@nortelnetworks.com>
(613) 831-6615