Subject: RE: LDAP Client Update: consideration of alternative proposals

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 27 May 2003 10:50:24 +1000

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-masked]]
Sent: Tuesday, 27 May 2003 01:11
To: [email-masked]
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

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 29 May 2003 12:57:31 +1000

It is sounding worse already. I'm referring here to the fact that you intend another draft saying HOW the syncing is to be done. Maybe the protocol can stand on its own, but I remember how the WG became fixated with the LCUP cookie. It is starting to sound as if this one will be bigger than "Ben Hur".

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Thursday, 29 May 2003 12:26
To: Ramsay, Ron
Cc: [email-masked]; [email-masked]
Subject: RE: LDAP Client Update: consideration of alternative proposals

At 06:07 PM 5/28/2003, Ramsay, Ron wrote:
>1) LCUP is meant to provide a simple synchronisation tool, similar to persistent search.

I content that LDAP-Sync is meant to provide a simple
synchronization tool, similar to persistent search, as well. The
primary applications being considered for both solutions is the
same: meta-directory, address-books, etc..

>2) Kurt's proposal seeks to define a replication paradigm.

While Jong and I certainly intend to use LDAP Sync as a basis
for single-master replication, this I-D does not attempt to
detail how LDAP Sync might be used for single-master replication.
(We saved that for a future draft.)

I note that this secondary intended use did not impose any
special requirements upon the protocol.  Like LCUP, LDAP-Sync
intends to meet the requirements of "applications intending
to synchronize heterogeneous data stores" [LCUP] and that easily
covers everything that a lightweight single-master replication
application needs from its content synchronization tool.

Now, maybe the difference is that LCUP focuses more on simple
application (e.g., address book) requirements and less on
sophisticated application (e.g. meta-directory) requirements,
but I think we each tried to meet the requirements of both
simple and sophisticated applications content synchronization
needs.

Kurt

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 29 May 2003 11:23:35 -0400

Generally, I agree with Ron's conclusion, that the WG should continue
with LCUP as it's been discussed and documented, and not try to morph
it into something new at this late date.
 
The lesson I have been/ continue to learn is that the IETF
standardization
process lends itself well to documenting established concensus, and
is lousy at documenting or arriving at new designs.
 
Kurt's work should proceed, as individual contributions, until there
are
there are sufficient collaborators to constitute the core of a working
group interested in further documentation of what they've learned
through
their joint development.
 
I swear I'm at the point of wanting to see the results of the first
interop
face-to-face meeting before constituting a new work group!  Think how
the history of DNSSEC and IPSEC would be different!  or LDUP, for that
matter!
 
Kurt has something worth while he wants to do - he should do it. 
Those
who agree that's worth while should work with him on it.  If those who
do so are part of the LDUP work group, then they should speak up and
be heard, now.  If not, then Kurt's work should continue outside the
WG.  If so, then I'd say there might not be anything the WG should do
but retire, while the competing designs settle out through competition
in the market place which is more use to customers, if indeed one
is better than the other.
 
To turn the tables, I don't recall the charter of the group including
a
bake off of competing designs, the thorough evaluation of competing
designs, etc. for LCUP.  If such is the desire of the WG, then by all
means change the charter ;-)  Until then, in the absense of
substantial
support for Kurt's proposal, it sounds to me like the LCUP direction
is
pretty well set.  It would be useful to have those interested in
continuing
the current LCUP direction voice their opinions, too, so the decision
to go forward is not simply a matter of momentum.
 
Ed
 
=================
Ed Reed
Novell, Inc.
+1 585 624 2402
[email-masked] 
Note:  Area code is 585

>>> Mark C Smith <[email-masked]> 5/28/2003 9:43:55 AM >>>

Chris Apple wrote:
>
> 2) It is an open topic for discussion. Specifically, John
>    and I need to see comments (preferably with rationale)
>    about the value (or lack thereof) of proceeding as
>    Kurt suggests. Do not wait for further communication
>    from either John, Kurt, or I to start this discussion.
>    John and I don't want to have to resort to interpreting
>    silence on this issue in one way or another.
> 
>    Make your opinions known NOW! This applies to you even
>    if you are an author of one of the drafts covered by
>    Kurt's request.

I suspect we are obligated to do something like what Kurt suggests: 
compare and contrast draft-ietf-ldup-lcup with
draft-zeilenga-ldup-sync. 
  If we don't, the ADs or IESG will probably make us do so eventually 
anyway.

But I am concerned about process issues surrounding this situation. 
Did 
the LDUP WG chairs declare consensus prematurely or inappropriately?  I

assume the ADs are involved and will help sort this out.  The authors
of 
draft-ietf-ldup-lcup did give serious consideration to the ideas 
presented in draft-zeilenga-ldup-sync; some of that discussion took 
place on the mailing list a while ago and some was private mail among 
the authors of the two documents. It is not as if the alternative 
proposal was ignored by the WG or by the LCUP authors.

One additional observation: to remain viable, the IETF needs to accept

and encourage contributions from many people, not just a few people. 
When a WG deliverable that has been nearly completed is derailed at the

last moment, the liklihood of the people who volunteered to work on
that 
deliverable doing so in the future is greatly reduced. Now, one could 
argue that this is not a technical consideration but a political one. I

would argue that it is both: the technical quality of the work done in

the IETF (and the likelihood of widespread implementation) is greatly 
influenced by the number of different implementors who contribute. For

LDAP related work, we seem to have fewer and fewer contributors each 
year. This is a problem.

> 4) John and I will await confirmation/clarification of our
>    understanding of Kurt's request from Kurt before making
>    the request to our ADs to slip the milestone date to give
>    us enough time to consider whether the WG wishes to:
> 
>     a) proceed as Kurt suggests
>     b) stay with our presently chartered course of action,
>        albeit with some slippage
>     c) take another path completely different from those

If you are asking for a vote, I vote for (b). But the larger procedural

issues (and the ADs) will probably dictate what we must do... and I 
suspect we will end up doing something close to (a).

-Mark Smith
  Netscape