Subject: LCUP and eventual convergence

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 01 May 2003 12:48:46 -0700

In http://www.imc.org/ietf-ldup/mail-archive/msg01612.html,
the chairs declared WG consensus:

  The server needs to be required to generate the set of 
  events necessary for eventual convergence of the client's
  copy of the DIT fragment.

I haven't been able to find where draft-ietf-ldup-lcup
mandates that servers generate the set of events necessary
for eventual convergence (or, if not possible, return an error).
I would have expected to find such a statement in the
introductory portions of the document as well as in 4.3.7.

Kurt

---

From: [email-masked] (Rich Megginson)
Date: Thu, 01 May 2003 14:24:32 -0600

This is the relevant text from lcup 05:

> If at any time during an LCUP search, either during the sync phase or 
> the persist phase, the server determines that it cannot guarantee that 
> it can bring the client's copy of the data to eventual convergence, it 
> SHOULD immediately terminate the LCUP search request and return a 
> SearchResultDone message with a resultCode of lcupReloadRequired.  
> This can also happen at the beginning of an incremental 
> synchronization request, if the client presents a cookie that is out 
> of date or otherwise unable to be processed.  The client should then 
> issue an initial synchronization request.

Note that this implies that the server DOES generate the set of events 
necessary for eventual client convergence, either though LCUP update 
responses or by notifying the client that a reload is required.

>introductory portions of the document as well as in 4.3.7.
If the current LCUP wording is not sufficient to convey this mandate, 
then may I ask for a suggestion of how to reword it?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 01 May 2003 14:54:49 -0700

At 01:24 PM 5/1/2003, Rich Megginson wrote:
>If the current LCUP wording is not sufficient to convey this mandate, then may I ask for a suggestion of how to reword it?

        In response to an LCUP request, the server SHALL either:
                a) generate the sequence of messages necessary for
                   eventual convergence of the client's copy of
                   the content to the server's copy of the content,

                b) indicate that a reload is required by returning
                   lcupReloadRequired, or

                c) return an resultCode other than success or
                  lcupReloadRequired.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 23 May 2003 11:53:32 -0400

As WG Co-Chair, I consider this issue to be resolved. Rich has pointed out
in another posting associated with this thread that the existing language
in the document actually does address the issue of eventual convergence.
As WG Co-Chair, I am satisfied that the authors have reflected previously
established WG Consensus on this issue.

We can work through any word-smithing or clarification language during
WG Last Call.

The WG Last Call announcement on LCUP will be posted to the list over
this coming weekend (perhaps even late today). Would do it now, but I'm
en route and have limited time to stay connected.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kurt D. Zeilenga
Sent: Thursday, May 01, 2003 5:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: LCUP and eventual convergence

At 01:24 PM 5/1/2003, Rich Megginson wrote:
>If the current LCUP wording is not sufficient to convey this mandate, then
may I ask for a suggestion of how to reword it?

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 May 2003 08:41:02 -0700

At 08:53 AM 5/23/2003, Chris Apple wrote:
>As WG Co-Chair, I consider this issue to be resolved.

I content that the fundamental issues raised during the
previous WG last call are not yet resolved.  That is,
I disagree that the editor of draft-ietf-ldup-lcup has
adequately addressed these issues.

>Rich has pointed out

---

From: "Chris Apple" <[email-masked]>
Date: Tue, 27 May 2003 08:28:24 -0400

Objection noted. My position as Co-Chair is that your opinion is
in the minority on this issue and therefore not consistent with the
consensus view on this matter.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com