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

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

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"?

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.