Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt

From: Robert Zuccherato <[email-masked]>
Date: Wed, 12 May 1999 14:12:40 -0400

Paul;

The intent was for precision to mean the delta between the time value and
the actual UTC when it was issued.  How about if I change the example to
"This precisionFactor would account for  50-Hz (20ms) or 60-Mh (16.67ms)
power-frequency clocks that are closely synchronized to UTC, for example."

	Robert.

> ----------
> From: 	Paul Koning[SMTP:[email-masked]]
> Sent: 	Wednesday, May 12, 1999 1:26 PM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> >>>>> "Robert" == Robert Zuccherato <[email-masked]>
> writes:
> 
>  >> Comment4 The description of the precision field is somehow
>  >> difficult to understand, and the name 'precision' is
>  >> misleading. It is not a precision, it is the precision factor. I
>  >> had to guess that 31.25 is actually a product of division of 1 by
>  >> 32.  My suggestion would be: "The precisionFactor field is an 8
>  >> bit signed integer. The actual precision of the clock is
>  >> calculated as a power(2, precisionFactor). Negative
>  >> precisionFactor value produces a precision as a fraction of a
>  >> second - for instance, precisionFactor=-5 would yield 2^(-5) =
>  >> 0.03125 sec (31ms). This precisionFactor would account for the
>  >> 50-Hz (20ms) or 60-Mh (16.67ms) power-frequency clock, for
>  >> example. Note that this method defines a precision of a clock as
>  >> 'being around the value', not as an exact figure."
>  >> 
>  Robert> Your wording is probably easier to understand.  Absent any
>  Robert> objections, I will use that.
> 
> I have a concern but it is common to the existing text and the
> proposed new text.
> 
> The term "precision" is not defined.  Several interpretations are
> possible, but the most natural one is contradicted by the example.
> 
> If the intent is that it indicates merely the step size of the local
> clock, the name should be "resolution", defined as the delta between
> one time value and the immediately following distinct time value.
> 
> If the intent is that it indicates the worst case error, i.e., the
> delta between the time value and the actual UTC when it was issued,
> "precision" is ok ("tolerance" might be even clearer).  But in that
> case, the example is misleading; while the tolerance of a 50 Hz clock
> clearly can't be significantly smaller than 20 ms, it might very well
> be a whole lot larger.
> 
> For the latter, some examples might be: (1) a fine resolution clock
> closely synchronized to UTC, for example with GPS -- 1 ms.  (2) a
> typical computer's clock synchronized to UTC once a day: 8 seconds.
> 
> Given a choice between the two interpretations, I strongly prefer the
> latter (i.e., tolerance w.r.t UTC); reporting resolution seems rather
> pointless. 
> 
> 	paul
>

---

From: "Michael Zolotarev" <[email-masked]>
Date: Fri, 14 May 1999 15:53:25 +1000

>power-frequency clocks that are closely synchronized to UTC, for example."

Sounds OK. Anticipating people to start arguing that "closely synchronised"
is a very loose definition, I can suggest adding something like:
"The actual method and frequency of synchronising the clock with UTC time,
as well as the characteristics of the clock itself, define the deviation
from UTC. As time stamp is not conceived to be used as a source of precise
timing, that information is not present in the stamp. However, the TSA's
policy MAY contain necessary details for interested parties".

MichaelZ