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

From: "Mark Meredith" <[email-masked]>
Date: Tue, 08 Feb 2000 12:20:34 -0700

Please publish - this reflects the changes requested via feed back on draft-00.

Please review this draft and submit comments.

-Mark

Mark Meredith
Novell Inc
122 E. 1700 S. Provo UT 84606
[email-masked]
801-861-2645
---------------------
A boat in the harbor is safe, 
but that is not what boats are for.
--John A. Shed
---------------------

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Feb 2000 12:30:16 -0800

Mark, a few comments:

I suggest that this draft be a informational elective feature.
I believe that prior operational experience with such features
have proven to be source of numerous interoperability problems.
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!).

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.

---

From: "Alexis Bor" <[email-masked]>
Date: Tue, 8 Feb 2000 12:43:50 -0800

Mark,
An initial reading of your draft raises lots of questions and concerns.  I
agree that from a client perspective, it would help to know how to behave in
specific situations.  At the same time, a server may want to also know how
to behave when communicating with another server.

It is a sad statement when client applications have to build up a knowledge
base to be able to work in every LDAP Server environment.  This raises the
value of groups like the Directory Interoperability Forum (DIF) - which
Novell and many others are members of.  I went to the last DIF meeting in
San Diego and wasn't fully convinced of their long-term relevance.  However,
I am now convinced that we need such an industry group to solve/document
interoperability issues.

Just think, when we have a directory of LDAP servers, you can quickly
connect to each server and build a profile of the brands that are out there
and maintain a census of brands and versions.  I don't know if this is good
or bad - but when I was a senior at UC Irvine, we had to take a class on the
"Social Impacts of Computing on Society".  This certainly would have been a
discussion topic.

Unfortunately, I don't see any other way for an application to manage its
behavior based on which vendor product it is connected to.  The current
process for LDAP standards has intentionally built a loose protocol that
makes behavior inconsistent between vendors.  This is chaos that most of us
are willing to live with.  Too bad...

-- Alexis

Alexis Bor
Directory Works, Inc.
[email-masked]
http://www.directoryworks.com

-----Original Message-----
From: Mark Meredith [mailto:[email-masked]]
Sent: Tuesday, February 08, 2000 11:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: please publish draft-mmeredith-rootdse-vendor-info-01.txt

Please publish - this reflects the changes requested via feed back on
draft-00.

-Mark

Mark Meredith
Novell Inc

---

From: "Peter Strong" <[email-masked]>
Date: Wed, 9 Feb 2000 10:10:06 -0500

Kurt/Mark

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> 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:
>

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!)

> 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.

> received requests (and patches) from users to do exactly

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.

>   Example: "NDS
> 2100-r1.2.3/NT4SP3/US-crypto-128-1.1/TurboBlaster-v2 compat FooDir"
>

Regards,

  Peter

------------------------------------------------------------------------
Peter Strong
Software Architect
Nortel Networks - Optivity Policy Services (OPS) and NetID
[email-masked] <mailto:[email-masked]>
(613) 831-6615

---

From: Mark Wahl <[email-masked]>
Date: Wed, 09 Feb 2000 09:50:14 -0600

Again, I believe this is the wrong approach to specifying server behavior 
and will not lead to interoperable clients.  

If there is a element of service X which two or more vendors implement 
differently, then there should be a proposal for a new attribute or similar
for the server to advertise how it implements X.

For example,

allowsMultipleSubschemas: TRUE

or

accessControlScheme: 1.2.3.4

A standards-track proposal would be best for each, because during the course
of discussion on the mailing list, we may find that the root DSE it not the 
best place for it, or there are more than an anticipated number of approaches
and so what was a BOOLEAN option flag might be better described some other way.

E.g. if a server uses chaining to automatically forward operations in a 
naming context to other servers which is a different implementation, then the 
capabilities that the chaining initiating server might advertise would 
potentially be more than if the server was not chaining.

Another example.  A server implementation allows the subschema subentry to
be modified to introduce new object classes, for compatibility with 
Netscape-oriented clients. It also allows subsubentries to be created below 
the subschema subentry to introduce new object classes, for compatibility with
Active Directory-oriented clients.  That server would advertise:

allowsSubschemaEntryModification: TRUE
implementsSubschemaLikeActiveDirectory: TRUE

> If a client relies on a vendorVersion number then that client MUST

I don't see how this would work at all.  If the first version of the server
ships on 1-JAN-2000, the client ships on 1-JAN-2001 and the next version of 
the server makes an incompatible change to something and ships on 1-JAN-2002,
that would mean that the client would need to know a year in advance what 
non-backwards compatible changes would be made.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.