Subject: Re: [ldapext] Re: I-D ACTION:draft-sermersheim-ldap-csn-02.txt

From: Howard Chu <[email-masked]>
Date: Fri, 04 Nov 2005 13:09:56 -0800

A couple of concerns were raised about using fractional seconds in the 
timestamp portion of the CSN. Mainly, that they do not always increase 
monotonically; some systems will decrement while adjusting the clock 
(e.g. using NTP?). The draft-ietf-ldup-model document specifically 
excluded fractional seconds; I think we need to continue with that 
restriction here.

Also wrt timestamps, expressing an implementation preference: I would 
like to see the timestamps restricted to UTC. As I see it, use of local 
time is really an issue of user-friendliness. As such, it's a matter for 
clients and user interfaces to deal with, not servers. And storing local 
time in the server is no friendlier if the client is querying from a 
remote timezone. I.e., the client must always be prepared to translate 
the server's timestamp into its localtime regardless, so storing 
localtime in the server doesn't save anything. It actually makes it 
harder for clients that are searching for CSNs greater than a specific 
time. Even if the server is "consistent" in its use of localtime - e.g., 
we just changed off of Daylight Savings Time, so there's an hour's worth 
of timestamps that overlap each other except for their offset. In this 
case, it's more developer-friendly to use UTC consistently.

> [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>> 	Title		: The LDAP Change Sequence Number
>> 	Author(s)	: H. Chu, J. Sermersheim
>> 	Filename	: draft-sermersheim-ldap-csn-02.txt
>> 	Pages		: 16
>> 	Date		: 2005-10-26
>> 	
>> This document defines a syntax schema element for the Lightweight 
>> Directory Access Protocol ([LDAP]) which is used to hold a Change 
>> Sequence Number (CSN). In general, a change sequence number 
>> represents the place and time that a directory entity was changed. It 
>> may be used by various attributes for various LDAP replication, and 
>> synchronization applications.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-02.txt

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: John McMeeking <[email-masked]>
Date: Sun, 6 Nov 2005 20:11:42 -0600

> excluded fractional seconds; I think we need to continue with that

Is eliminating fractional seconds from the CSN the way to address the
problem of decreasing CSNs?  Would it be more appropriate to require that
any CSN generator generate strictly increasing sequences of CSNs with
respect to the time and timeCount components?  I believe there is a similar
requirement for the DCE UUID time-based variants.

On that note, this document doesn't say much about the use or behavior of
the timeCount field, though some use is implied by the ordering rule.

John  McMeeking

---

From: Howard Chu <[email-masked]>
Date: Sun, 06 Nov 2005 21:51:00 -0800

> requirement for the DCE UUID time-based variants.

Yes, we probably need an explicit statement to this effect, since that 
is the actual concern. Eliminating fractional seconds helps simplify 
conformance to this requirement, otherwise there is no bound on the 
resolution necessary to meet the requirement.

> the timeCount field, though some use is implied by the ordering rule.

Yes, I suggested to Jim that we should provide examples / use cases for 
these fields but there wasn't time to get those in.