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

At 06:18 AM 3/11/2003, Rich Megginson wrote:
>Kurt D. Zeilenga wrote:
>>
>>At 06:40 PM 3/10/2003, Rich Megginson wrote:
>>  
>>>>>>
>>>>>>Lack of "eventual convergence data consistency"      
>>>>>>          
>>>>>
>>>>>What does LCUP currently state?
>>>>>        
>>>>
>>>>Presently, the I-D is a bit lacking in its data consistency
>>>>statements.  It needs to be more explicit in stating that
>>>>servers are to either generate messages which will lead to
>>>>convergence or return an error.  This, I think, can be resolved
>>>>by rewording portions of 3.3.7.
>>>>      
>>>
>>>Reword to say what?
>>>Change the SHOULD in the first paragraph of 3.3.7 to a MUST?
>>>    
>>
>>
>>The first paragraph says what the server is to do if it detects
>>an inconsistency.  It does not require the server to implement
>>any inconsistency detection.
>>
>>It's my opinion that the server should be REQUIRED to either
>>produce a set of messages which cause convergence at conformant
>>client or return an appropriate error.
>>
>>Kurt 
>>  
>To summarize the discussion of the past two days - there are a couple of problems with the current LCUP 04 draft:
>
>1) The draft has an implicit assumption that the server will store some historical change information in order to reduce the amount of data sent to the client during resync.  This precludes server implementations that do not store any historical information.  Such a server could simply use the createTimestamp or modifyTimestamp

(or entryCSN)

>in conjunction with a cookie that simply has a timestamp as its value. This server could just return all entries whose createTimestamp and modifyTimestamp are greater than the timestamp in the cookie, and return only a DN or UUID for other entries within the search scope.  The client would presume those entries have not changed.  At the end of the sync session, the client would assume that entries that have not been received in full (changed entries) or entries for which a DN or UUID has not been received (unchanged entries) have been deleted or moved out of the search scope.

>I think the LCUP draft could be changed to allow this, but this would be an optional feature of the protocol.

I assume you mean optional to the server...

>However, I would like to know of any existing or planned server implementation that does not store any historical information, either in a state or log based system.  Could I see a "show of hands"?

OpenLDAP has "early" no-history implementations of LCUP (circa
-03) and LDAP-Sync presently available for experimentation.

>2) The draft should state an absolute convergence requirement.  That is, the server is REQUIRED to do one of the following:
>Produce a set of operations that will bring the client into complete synchronization with the server
>Tell the client that incremental synchronization is not possible and require the client to do a full resync
>
>I believe this could be easily done with some slight rewording of section 3.3.7 of the LCUP 04 draft.
>
>Are there any other problems?  Come on, don't be shy.

Many (mostly minor).  When I first looked at -04, I found many of the
same problems I found in -03 (and raised in my "laundry list"
and/or the WG Last Call).  I have not yet attempted to put an
updated "laundry list" together for -04, I prefer to remain focused
on a couple of critical issues.

Kurt