Subject: Re: I-D ACTION:draft-ietf-ldup-lcup-04.txt

From: John Merrells <[email-masked]>
Date: Mon, 10 Mar 2003 20:58:54 -0800

Jonghyuk Choi wrote:

>Because the protocol does not explicitly exclude the so called 'no-history'
>implementation, the server would have to return lcupReloadRequired
>so often to achieve a reasonable degree of consistency.
>
Yep.

>An optimization for this is that the client sends a lightweight
>reload request to the server in response to lcupReloadRequired.
>The server then sends the entries changed after the client cookie
>as normal search entries and sends only DNs and UUIDs of unchanged
>entries in order to reduce chattiness. The client can then consider
>unarrived entries as deleted or scoped-out ones and delete them.
>
In this case the server is using some historical information to optimize the
amount of information that needs to be sent back to the client. The more
historical information stored the more you can optimize the amount of data
that needs to be sent back.

John

---

From: [email-masked] (Mark C Smith)
Date: Tue, 11 Mar 2003 09:56:04 -0500

> that needs to be sent back.

Exactly. There is a big tradeoff here between complexity of 
implementation and the efficiency of the LCUP protocol exchange. It is 
important to allow implementors to have some flexibility while still 
assuring that the protocol works reliably. In many cases, efficiency 
tradeoffs can and should be left in the hands of the implementors.

-Mark Smith
  Netscape

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 11 Mar 2003 07:33:54 -0800

At 06:56 AM 3/11/2003, Mark C Smith wrote:
>Exactly. There is a big tradeoff here between complexity of implementation and the efficiency of the LCUP protocol exchange. It is important to allow implementors to have some flexibility while still assuring that the protocol works reliably. In many cases, efficiency tradeoffs can and should be left in the hands of the implementors.

I would agree that in many (if not most) cases, such tradeoffs can
be and should be left in the hands of the implementors.

However, where behaviors of one implementor is likely to cause
harm to others (either its peer or to other components of the
Internet), we need to place restrictions upon all implementor
to prevent that harm from occurring.

Kurt