Re: LDAP C API -> Informational

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

> I believe the current draft could be published as Informational
> without significant delay.

RFC 2026, the process for Internet standards, states in section 4.2.3 on the
procedures for Experimental and Informational RFCs:

   To ensure that the non-standards track Experimental and Informational
   designations are not misused to circumvent the Internet Standards
   Process, the IESG and the RFC Editor have agreed that the RFC Editor
   will refer to the IESG any document submitted for Experimental or
   Informational publication which, in the opinion of the RFC Editor,
   may be related to work being done, or expected to be done, within the
   IETF community.  The IESG shall review such a referred document
   within a reasonable period of time, and recommend either that it be
   published as originally submitted or referred to the IETF as a
   contribution to the Internet Standards Process.

   If (a) the IESG recommends that the document be brought within the
   IETF and progressed within the IETF context, but the author declines
   to do so, or (b) the IESG considers that the document proposes
   something that conflicts with, or is actually inimical to, an
   established IETF effort, the document may still be published as an
   Experimental or Informational RFC.  In these cases, however, the IESG
   may insert appropriate "disclaimer" text into the RFC either in or
   immediately following the "Status of this Memo" section in order to
   make the circumstances of its publication clear to readers.

   Documents proposed for Experimental and Informational RFCs by IETF
   Working Groups go through IESG review.  The review is initiated using
   the process described in section 6.1.1.

The LDAPEXT working group has been chartered with the development of a C 
API for LDAPv3 as its work item.  A quick scan of my email shows that there
has been active engineering work on this draft by at least four people for 
over a period of two and a half years.  At previous IETF meetings there 
appeared concensus to put forward this document as a Proposed Standard, 
and a second working group last call was issued in October of this year. 
I believe it would not be appropriate to publish this draft as Informational,
as it is not normal IESG procedure to publish a draft as Informational partway
through its standards process.

 - If the specification is technically complete, then it should be sent to the
   IESG for IETF-wide review and become a proposed standard.

 - If the specification has technical errors, then it should be returned to the
   working group so the errors can be fixed, and we go through last call again.

 - If the working group produces output which either ignores the contributions
   of its members, or consistently makes incorrect technical choices, then the
   group has a problem which needs to be resolved.

The goal of the last call is to answer the question, does the C API 
specification have technical errors, and if so, are there problems in the 
LDAPEXT working group that would prevent these errors from being resolved?

Since (1) some of issues have been sent directly to the document authors, (2)
the opinions of the authors may or may not have changed in the last few 
weeks, (3) perhaps not all of the authors have been involved in offline
discussions, and (4) the opinions of the authors are not known to the working
group as a whole, I propose the following procedure be used to provide an 
opportunity for the authors as a group to ensure that they have a consistent 
opinion on the issues you have raised, and then to provide this as a basis for 
discussion in the working group as a whole. 

Kurt and the document authors (Anoop Anantha, Andy Herron, Tim Howes, Mark 
Smith, Mark Wahl) should meet as a group, either by email or teleconference, 
and review Kurt's issues list. (I want to hold that discussion privately off 
of ietf-ldapext so that the participants can feel free to have exploratory or 
hypothetical discussions without these being misinterpreted as statements of
intended direction.)  As a result of this meeting, this group will send a 
single email to ietf-ldapext that outlines the issues raised by Kurt, and for 
each issue, the view of the document authors on how it should be resolved.

The working group will then have this as a basis to decide how to complete 
the last call.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.