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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 29 May 2003 11:07:03 +1000

As I see it

1) LCUP is meant to provide a simple synchronisation tool, similar to persistent search.
2) Kurt's proposal seeks to define a replication paradigm.
3) The WG failed to pursue replication to a standard.
4) All the discussion I've seen seems to be between the competing authors.

Therefore, I believe you have to accept the original LCUP proposal with possible tweaks. There aren't enough voices left in this group to undertake any new work.

Ron

-----Original Message-----
From: Chris Apple [mailto:[email-masked]]
Sent: Thursday, 29 May 2003 02:20
To: 'Mark C Smith'
Cc: 'Kurt D. Zeilenga'; [email-masked]; 'John Strassner'
Subject: RE: LDAP Client Update: consideration of alternative proposals

Thanks for taking the time to post on this topic.

I've included a response to the process concerns below.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com

-----Original Message-----
From: Mark C Smith [mailto:[email-masked]] 
Sent: Wednesday, May 28, 2003 9:44 AM
To: [email-masked]
Cc: 'Kurt D. Zeilenga'; [email-masked]; 'John Strassner'
Subject: Re: LDAP Client Update: consideration of alternative proposals

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.

<CHRIS>

From a process perspective, we are obligated to consider Kurt's request.

If consensus is established supporting Kurt's request we become obligated
as a WG to pursue that course of action once that consensus is declared
by John and I.

</CHRIS>

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.

<CHRIS>

With regard to the WG Co-Chairs having declared consensus prematurely
or inappropriately, the jury may be out. I know I have an opinion on
that matter and that's that we did the best we could given the input
received on the mailing list. Currently, this question is not one that
is being formally considered by the ADs.

The ADs were and are involved. That Kurt made the posting to the mailing
list making his request was a result of private discussion held between
Kurt, myself, John Strassner, and both of our ADs. Kurt expressed his
concerns to us privately; we were unable to come to agreement on how to
handle his concerns as a part of the WG Last Call for LCUP; we made a
decision as Co-Chairs that Kurt should take his concerns along with
a specific proposal to the WG Mailing List. John and I have endorsed
the consideration of Kurt's proposal by the WG. That's how we got here.

I agree that the proposal presented in draft-zeilenga-ldup-sync was
given adequate consideration by the LCUP authors and the WG. But again,
the jury may be out on that point. It is still a valid question to ask
though.

Speaking as a Co-Chair, I would have preferred to see all of the technical
discussion between the two author teams related to these two drafts taking
place on the LDUP WG mailing list.

I am hoping that all future discussion related to this topic takes place
on the mailing list.

</CHRIS>

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.

<CHRIS>

I share that concern whole-heartedly.

</CHRIS>

> 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).

<CHRIS>

The WG will end up doing whatever we establish consensus on. The prior
consensus
is reflected in the current charter. That was reflected in (b). This
discussion
is intended to help us as Co-Chairs determine if there is more support for
one of the options above or another.

Interpreting that requires input on the mailing list. I only hope that
others
are inclined to contribute to the discussion as you've done.

</CHRIS>

-Mark Smith
  Netscape

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 May 2003 19:26:01 -0700

>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: "Chris Apple" <[email-masked]>
Date: Wed, 28 May 2003 23:48:40 -0400

Kurt,

Does this mean that you agree with Ron's point? Or not?

DSI Consulting, Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 May 2003 21:23:01 -0700

>Does this mean that you agree with Ron's point? Or not?

I don't dispute Ron's point that LCUP (draft-ietf-ldup-lcup)
is meant to provide a simple synchronization tool.  However, I
added that I believe that LDAP-Sync (draft-zeilenga-ldup-sync)
is also meant to provide a simple synchronization tool.  I'll
leave it to Ron to say whether he concurs with my additional
point.