Fair enough. Though with a definition like that, it's formally
impossible to distinguish bugs from intentional behavior ("features").
Anyway, I'm guessing you know the design intent, as well as the relevant
implementations, pertaining to the question I posed further down in that
email, namely:
Is the leap bit supposed to be cleared by a client if it gets LI=00 from
a server? Or is the bit only *set* based on information from a server,
and cleared only upon application of the leap second? If the latter is
the current implementation, it might well explain the bogus leap second
behavior many of us saw a few days ago. Unless you have a different
explanation/understanding?
Thanks,
--Jeff
On 8/3/2012 5:08 PM, Harlan Stenn wrote:
Jeff wrote:
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres to NTPv4, not v3.
The NTP code *defines* the spec, and there will be times when the
current spec and the code match, and there are times when the current
code is getting ready to define the *next* spec.
For what it's worth the most recently approved protocol is, technically,
NTPv3, documented in RFC1305 - and that one does say "current day" -
though again, ntpd respects the end-of-month rule.
That depends on your definition of "Approved". NTPv3 (RFC 1305) never
made it out of DRAFT status.
RFC 5905 is a "Proposed Standard".
H
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
