Some LCUP Issues

Hi. I'm Jong Choi of IBM Research.
Below are the issues I found in the LCUP draft.

<Section 4.4>
It is stated that the server SHOULD send the cookie
in the entryUpdate control for every sendCookieInterval 
number of SearchResultEntry PDUs to the client.
It seems  not clear whether this applies to synchronize
as well as persist.
(Below, I assumed RUV (as in section 7) as the cookie.)
In the case that RUV is returned to the client periodically
during a synchronize session, it may not have much 
meaning unless the returned entries are sorted 
(as in size limit case in section 7).
Otherwise, upon error during a synchronization session, 
the next synchronization should restart from
the RUV before the failed synchronization not from the last 
received RUV before error.
If this is the case, periodic delivery of cookies during 
a synchronize section may be meaningless.

<Section 4.5>
The contents of this section seems to be applied to persist scenario only.
The synchronization case need to be considered as well in this discussion.

<Section 4.6>
>   If server resources become tight, the server can terminate one or 
>   more search operations by sending a SearchResultDone message to the 
>   client(s) with a resultCode of lcupResourcesExhausted. Unless the 
>   client sets the updateType field to persistOnly, the server attaches 
>   a clientUpdateDone control that contains the cookie that corresponds 
>   to the current state of the client's data. A server set policy is 
>   used to decide which searches to terminate. This can also be used as 
>   a security mechanism to disconnect clients that are suspected of 
>   malicious actions, but if the server can infer that the client is 
>   malicious, the server should return lcupSecurityViolation instead.

Does synchronizeAndPersist become the same as persistOnly
after the latter finishes the initial priming ?
Hence, we need to distinguish whether a synchronizeAndPersist
in the initial mode and in the change notification mode
to be able to terminate synchronizeAndPersist in the initial mode only.

On the other hand, it may be required for the server to terminate
persistOnly or synchronizeAndPersist in the change notification mode.
If there are too many persist searches to take care of upon modification,
it may be required to terminate some of them to limit their performance impact.

<Section 4.9 and the following paragraph from Section 7>
>   An implementation must make sure that it can correctly update the 
>   client's cookie when there is a size limit imposed on the search 
>   results by either the client's request or by the server's 
>   configuration. If RUV is used as the cookie, entries last modified 
>   by a particular master must be sent to the client in the order of 
>   their last modified CSN. This ordering guarantees that the RUV can 
>   be updated after each entry is sent.

It seems that the above paragraph also holds when a time limit is imposed.
A possible issue with the time limit is that the time to sort the result set
may be larger than the time limit itself. 
The sorting may also be required when we decided to cope with errors during
a synchronization session in such a way that avoids restart from the pre-session state.

<Section 5.1>
The issue of leftSet change type in the triggered search change type support
needs to be brought out to the general discussion of how to maintain the convergence.

<Section 7>
It is said that an LDUP compliant server can notify the client of the deletion
using the tombstone. It is not clear how this notification is delivered to the client,
whether the deleted entries are automatically delivered to a client as a part
of the resynchronization or the client has to issue separate resynchronization
search to tombstone to get the list of all deleted entries after the last
synchronization time. Because only a small set of required attributes 
are retained in the tombstone, it may happen that a search specification cannot 
match entries in the tombstone using its filter containing non-retained attributes.
In this case, it seems that all the deleted entries after the last synchronization
point should be delivered to the client. LCUP clients needs to request synchronization
at least more frequently than the lifetime of the entries in the tombstone. It would be
helpful for the server to optionally deliver this lifetime value as a part of control,
so that the client may consider this value when deciding the synchronization interval.

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: [email protected], [email protected]
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979