RE: LDAP Client Update: consideration of alternative proposals

At 05:24 AM 5/27/2003, Chris Apple wrote:
>Kurt,
>
>There are a few major points I'd like to be sure I'm 
>summarizing correctly before John and I respond on the
>procedural issue. You are requesting the following:
>
>1) that the WG formally consider your individual
>   contribution as an alternative to the existing
>   WG deliverable for LDAPv3 Client Update Protocol.
>
>2) that the WG evaluate both documents based on
>   technical merit.
>
>3) that the WG emerge from that evaluation process
>   with a single document that will be processed
>   through a WG Last Call and submitted to the Ads
>   as the WG deliverable for LDAPv3 Client Update
>   Protocol.
>
>4) that the WG Last Call milestone for LCUP be
>   rescheduled further out in time to accommodate
>   the above.
>
>Did I miss any key points in your request?

I believe you have captured the key points of my request.

>Do any of them need clarification?

I believe your summary of my request does not need clarification.


>Chris Apple - Principal Architect
>
>DSI Consulting, Inc.
>
>mailto:[email protected]
>
>http://www.dsi-consulting.com
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:[email protected]] 
>Sent: Monday, May 26, 2003 11:11 AM
>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