RE: LDAP Client Update: consideration of alternative proposals

Just a procedural point: are there enough 'active' members left in this group to advance either document? (I am not active.) If the issues are debated only by the authors then I don't think either proposal should be advanced.

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email protected]]
Sent: Tuesday, 27 May 2003 01:11
To: [email protected]
Cc: Chris Apple; John Strassner
Subject: LDAP Client Update: consideration of alternative proposals



The LDUP WG is chartered to deliver:
  o LDAPv3 Client Update
        A protocol that enables an LDAP client to
        synchronize with the content of a directory
        information tree (DIT) stored by an LDAP server
        and to be notified about the changes to that
        content.

Over the last few years, the WG has engineering a technical
solution for this deliverable.  This solution is specified
in the I-D draft-ietf-ldup-lcup.  Over the last 9 months or
so, Jong and I, acting on an individual basis, engineered
a technical solution for this deliverable.  This solution is
specified in the I-D draft-zeilenga-ldup-sync. 

Each of these technical solutions are intended to fulfill
this deliverable.  I also believe both sets of authors
believe that their approach best fulfills this deliverable.
It is also likely many members of this WG have formed opinions
as to which technical solution best fulfills this deliverable.
However, it is unclear to me whether both I-D, in particular
the most recent revisions of each, have been thoroughly
considered by the WG.

WG I-Ds are implicitly viewed as being under WG consideration
and it hoped that significant number of WG members review the
I-D as it evolves.  Individual I-Ds are not necessarily viewed
as being under WG consideration unless submitted to the WG for
consideration by their authors.  They generally are reviewed by
few WG members until consideration is specifically requested.

I now submit the draft-zeilenga-ldup-sync to the LDUP WG
for consideration as a technical solution to its "LDAP Client
Update" deliverable.  I believe the latest revision,
draft-zeilenga-ldup-sync-02.txt, is suitable for progression.

I ask the WG to view draft-ietf-ldup-lcup and draft-zeilenga-ldup-sync
as technical alternatives and give thorough consideration to both.
It is up to the WG to decide which solution is technically
superior.  As it is the function of the WG Chairs to manage the
group process, I defer procedural questions and issues to Chris
and John.

As the differences between the approaches is fundamental in
their design, it will be difficult to compare them without some
basis to which can be measured against.  It may be appropriate
for the WG to examine what kinds of applications it intends its
deliverable to be applicable to, what the requirements of these
applications are, and how each of the technical alternatives
measures up to these requirements.  The WG should also consider
broader issues, such as chattiness and security considerations.
The WG should consider the appropriateness of the design and
other constraints each places upon implementations.

In regards to the WG milestone:

   May 03    LDAPv3 Client Update Protocol I-D goes
             to WG Last Call as Proposed Standard 

I would like the WG to defer this WG Last Call until it has
thoroughly consider both technical alternatives and reached a
consensus as to which alternative it would like to pursue.
Then that alternative should be prepared of WG Last Call as
the WG's "LDAPv3 Client Update Protocol I-D".  I believe it
necessary to defer the WG Last Call as the WG first needs to
thoroughly consider both alternatives.

I'd like to say a key design difference which is a major factor
in I considering draft-zeilenga-ldup-sync technically superior
to draft-ietf-ldup-lcup.  In attempting to implement
draft-ietf-ldup-lcup, we found that requires server implementations
to maintain complete history information in order to provide
eventually convergent incremental refreshes.  We found that
where the server only maintains simple state indicators such as
timestamps, it cannot generally provide eventually convergent
incremental refreshes.  If the server maintains partial histories,
the server will be limited in cases where it can provide
eventually convergent incremental refreshes.  In October 2002,
the WG consensus was declared on an alternative approach (but
later recanted).  We implemented this approach and found that it
allowed all of the above implementation variants to provide
eventually convergent incremental refreshes.  This was document
in documented in early revisions of draft-zeilenga-ldup-sync.
As a result of WG discussions about this approach, it was noted
that this approach didn't allow servers to take advantage of
histories they maintained.  In our latest revision, we adopted
a hybrid approach which allows servers to take advantage of
histories they maintained.  Hence, I believe draft-zeilenga-ldup-sync
is technical superior in that it does not place significant
implementation constraints in order to support eventually
convergent incremental refreshes while allowing implementations
take advantage of histories they maintain.  There are, of course,
many other factors in my consideration and I am quite willing to
elaborate on these in subsequent discussions.  Before doing so,
I will await direction from the chairs on how to proceed with
the consideration of the alternatives.

Comments?

Regards, Kurt