Re: Tw bobs worth on TOP, LDAP standards process and subschemasub entry attribute usage in rootDSE

[Mark Wahl <M.Wahl@INNOSOFT.COM>]

I wish to address your concern that that there is a problem with the LDAP 
standards process because a few implementors have not followed the IETF/ISO 
standards and ITU-T recommendations regarding 'top'.

It appears to me that there are vendors who have been unaware or uninterested 
in the X.500 features available through LDAP that would enable them to address 
their customer base requirements without modifying 'top'.  Their changes 
have shown up as bugs in inter-vendor interoperability testing, and the vendor 
responses have tended to be of the following:

 - acknowledged the problem and fixed in a subsequent release

 - acknowledged the problem but not yet fixed it

 - there is no problem as inter-vendor interoperability is not of interest to 
   their customer base

While this is unfortunate in individual cases for those deploying 
implementations which do not interoperate, I view this as a natural effect of
the open-to-any-implementor standards process as practiced by the IETF.

Background on the IETF standards process

The standardization of LDAP has followed and continues to follow the guidelines
for any IETF standard.

The goal of the IETF standards process in a specification that is
"...stable and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with substantial operational
experience, enjoys significant public support, and is recognizably useful
in some or all parts of the Internet." (RFC 2026 section 1.1)

The requirements statements in RFC 2251-2256 are based on RFC 2119, and
implementations which follow the specifications are expected to interoperate.

The Draft Standard level, to which LDAPv3 RFCs 2251-2256 would next progress,
has the requirement that "two independent and interoperable implementations 
from different code bases have been developed, and for which sufficient 
operational experience has been obtained" (RFC 2026 section 4.1.2). This 
applies to all aspects of the RFCs, including schema and the information model.

These requirements are there because implementations of the Proposed Standard 
may have bugs that show up in testing with another implementation, or 
clarifications to the specifications may be necessary to achieve 
interoperability.

I believe that it will be possible to show that there have been two independent
implementations with operational experience which both implement LDAPv3 
correctly, including the 'top' object class.  Furthermore, I believe that a 
significant majority of the implementations correctly implement the 'top' 
object class.  This will be shown in a document from Tim Howes and I when these
RFCs are ready to go to Draft Standard level, as described in the third 
paragraph of RFC 2026 4.1.2.  

Please note that these requirements are based on selecting independent 
implementations for which there has been suffficent operational experience.

It does not require that every pair of implementations have been tested and 
shown to interoperate, nor does it require that the implementation with the
largest number of operational deployed sites be shown to interoperate with
the second largest, so long as there are other interoperable implementations 
with sufficient operational expereince.

Historical outcome of the IETF standards process

Overall, the IETF standards process has resulted in a series of protocol specs
that for the most part products which follow are able to interoperate.

However, this world has not been perfect.  Most modern and widely-deployed 
implementations of TCP/IP and popular application-layer protocols include 
at last one workaround for a problem with some specific vendor implementation.
Perhaps an early version of that vendor's product is still in wide use, or
new versions of the vendor's product continues to be noncompliant. In some
cases the most widely deployed implementation may be noncompliant.  

Over time, it has been the case that major deployed implementations of TCP, HTTP
SMTP or MIME have had serious interoperability problems.  Many of the other 
implementors of these protocols have had to put in 'hacks' in their code to 
deal with noncompliant products sending them illegal data or not being able to
handle legal data.  The same problem also has applied to ITU-T recommendations 
and the implementations of them, BTW.

The IETF standards process does not enforce conformance.  The IETF does not 
operate a branding program, have an enforcement arm, trademark or license the 
elements of protocol.  The IETF does not tend to sue implementors when their
products are nonconformant.  Furthermore, an application protocol such as LDAP
would have either Recommended or Elective status: even FTP or SMTP do not have 
the Required status. 

Therefore, the same can be anticipated for LDAP as with any other popular 
standards-track application protocol:

 - There are many independent implementations.

 - Most implementations interoperate.

 - There are implementations which send data to port 389 that is not legal LDAP.

 - There are implementations which listen on port 389 but do not support 
   certain key LDAP features.

 - Some of these noncompliant implementations have become widely deployed.

 - The IETF would be unlikely to 'require' an implementor to fix a noncompliant
   LDAP implementation.

If there were serious problems where the majority of implementations could not
interoperate, then this is an issue that the document authors should address
by revising the document.   However, I have not seen this occur in LDAPv3.

There are alternatives to the IETF standards process, of course.  The 
University of Michigan could have chosen to 'license' the LDAP specfication to
other implementors and require them to pass a conformance test before shipping.
Some vendors attempt to patent their server design or protocol extensions.   
As a result, there would be a legal means to enforce conformance to a protocol 
specification.  Hoewver, it would be significantly less likely to be permitted 
to result in an Internet Standard. First, RFC 2026 10.3.2 (C) requires the 
assurance that when it becomes a Proposed Standard, "...any party will be able 
to obtain the right to implement, use and distribute the technology or works
when implementing, using or distributing technology based upon the specific 
specification(s) under openly specified, reasonable, non-discriminatory terms."
Second, the IETF would be more likely to choose a technology for standardization
that has fewer IPR encumberances over one with more.  None of the popular IETF 
application layer protocols have a requirement for conformance testing before
an implementation can be shipped.

There are several ways to work in the IETF standards process to improve matters:

 - review your implementation against the standards-track RFCs and reference
   documents

 - take your implementation to interoperability tests and publish the 
   results of testing with your implementation and others

 - encourage other implementors to follow standards where appopriate: they
   may be unaware of them

 - send email to the document editors where clarifications are needed

 - encourage communities of deployers to evaluate implementations on a 
   technical basis by reviewing interoperability test results

Mark Wahl, Directory Product Architect
Innosoft International, Inc.