Subject: Re: [IDWG] ntpstamp rollover and UTC

From: "David A. Curry" <[email-masked]>
Date: Tue, 02 Jan 2001 08:54:18 -0500

>A third problem with ntpstamp is that RFC1305 states that the value
>0x0000000.0x0000000 is reserved to mean 'invalid' or 'undefined', and is meant
>to be used when a device's clock has not yet initialized.  However, this value
>will occur at the instant of the rollover in 2036, causing a momentary
>discontinuity.  I think we can handle that by redefining this special value to
>mean 2036-02-07T06:28:16Z (i.e. the instant of the rollover), and there is no
>'invalid' value.  (Yes, I know, this is nit-picky since it will only occur
>once)

Um, do we really need to define this?

Both RFC1305 (NTP) and RFC2030 (SNTP) don't seem to care -- they simply say
there's a 200-picosecond interval, "henceforth ignored," every 136 years
when the 64-bit field will be zero.

I would prefer to simply note this and suggest that sensors do "something"
(add a picosecond or whatever) to avoid sending an all-zero value unless
they really mean it.  This strikes me as "better" than redefining what a
particular timestamp means.

>Because of all these deviations from RFC1035, it may eliminate ambiguity if we
>state that the ntpstamp format is derived from RFC1035, rather than that it
>conforms to the RFC.

I'm confused -- what deviations do we have?

If we handle the all-zeros issue as above, and include the SNTP language about
handling the rollover (the 1968-2036/2036-2104 stuff), we don't actually have
any real deviations, do we?  We just send the timestamps NTP gives us, with
no changes.

I think you're right anyway and we should use the word "derived" instead of
"conforms," but do we really have any deviations?

--Dave

---

From: Paul Sangree <[email-masked]>
Date: Tue, 02 Jan 2001 09:29:06 -0600

>particular timestamp means.

That'd be fine with me.

>any real deviations, do we?  We just send the timestamps NTP gives us, with

You're right.  I was thinking of the rollover solution as a deviation, but it
is really just a matter of how to interpret the data rather than a change in
the value of the data.

---------------------------------------------------------------
Paul Sangree <mailto:[email-masked]>
Active Audit Engineering
Cisco Systems, Inc.
12515 Research Blvd, AST03/B2-6
Austin, TX, USA 78759
voice: 512-378-1518
fax:    512-378-1250

---

From: Stuart Staniford <[email-masked]>
Date: Mon, 15 Jan 2001 16:11:10 -0800

[Sorry, I'm catching up on IDWG mail after a busy period.]

I don't understand why there's a rollover problem, given that our
representation is indefinite length ASCII.  Why not just keep letting the
numbers grow beyond what can be held in 32 bits, and leave it to
implementations that want to use a 32 bit type to figure out how to
correctly munge it?

Stuart.

-- 
Stuart Staniford  ---  President  ---  Silicon Defense
[email-masked]  http://www.silicondefense.com/
(707) 445-4355                     (707) 445-4222 (FAX)

---

From: "David A. Curry" <[email-masked]>
Date: Tue, 16 Jan 2001 07:44:34 -0500

>implementations that want to use a 32 bit type to figure out how to

The problem I can see here (and maybe we don't care) is if different people
deicde on different ways to "correctly" munge it.  Personally I find it
more "aesthetically pleasing" if we Do The Right Thing and acknowledge
the problem and recommend the One True Way to deal with it.

--Dave

---

From: Dug Song <[email-masked]>
Date: Tue, 16 Jan 2001 09:40:38 -0500

On Tue, Jan 16, 2001 at 07:44:34AM -0500, David A. Curry wrote:

> Personally I find it more "aesthetically pleasing" if we Do The
> Right Thing and acknowledge the problem and recommend the One True
> Way to deal with it.

see djb's TAI64 format:

	http://cr.yp.to/y2k.html
	http://cr.yp.to/proto/utctai.html
	http://cr.yp.to/libtai/tai64.html

additionally, libtai is in the public domain.

-d.

---
http://www.monkey.org/~dugsong/

---

From: "David A. Curry" <[email-masked]>
Date: Tue, 16 Jan 2001 10:15:24 -0500

>see djb's TAI64 format:

While this might be useful, it doesn't solve our problem in this case.  We
have a requirement from the IESG to use NTP.  Given that...

--Dave

---

From: Paul Sangree <[email-masked]>
Date: Tue, 16 Jan 2001 10:11:45 -0600

>the problem and recommend the One True Way to deal with it.
The reason there IS a rollover problem is that the DTD document references the
NTP rfc to define the implementation of ntpstamp, and since that rfc doesn't
provide a solution to the rollover problem, we need to define 'some' solution
in order to prevent chaos (assuming you're willing to stretch your imagination
that IDMEF will still be in use in 35 years).  If there is a "One True Way" in
this case, I think it would be the SNTP windowing scheme I proposed
previously.  That is the mechanism most likely to be used by systems that
implement NTP or SNTP, so there shouldn't be any translation needed to generate
a ntpstamp from the NTP time value.