[ntp:questions] WARNING: someone's faking a leap second tonight
unruh at invalid.ca
Sun Aug 5 20:24:10 UTC 2012
On 2012-08-04, Harlan Stenn <stenn at ntp.org> wrote:
> unruh writes:
>> On 2012-08-04, David Woolley <david at ex.djwhome.demon.invalid> wrote:
>>> Harlan Stenn almost wrote:
>>>> The NTP reference implmentation *defines* the spec, and there will
>>>> be times when the ...
>> And it is a reference implimentation, not the definition. Ie, it is an
>> implimentation that is supposed to follow the standard. It does not
>> define the standard.
> You can believe what you want.
> In this case you are kinda wrong. But perhaps it's a matter of
> The reference implementation *in this case* is the target the RFC
> intends to meet. The current RFC is developed and written based on what
> the then-current ntp-dev implements.
Except of course that the reference implimentation contains a huge bunch
of stuff that is never intended to be part of the rfc ( the exact order
fo the statements, the exact implimentation details, etc). As it is the
rfc already defines far too many things that are accidents of
theimplimentation rather than design specifications that any
implimentation should meet.
For example the code contains bugs. If the code is supposed to be the
defining structure, then of course there are no bugs, just features. The
leap second hangs the whole implimentation? That is as it should be. The
implimentation does a leapsecond round robin so that it never shuts off?
Thatis as it should be. After all the code defines ntp. That would be an
absurd position to take. Now the RFC may be an abstraction from the
code, but again, one wants to make sure that it is a sufficiently
generic abstraction that may valid implimentations are possible.
> There comes a time when the RFC is left as a marker and the code moves
> on, in preparation for the next RFC.
>> > Also, I don't think this is the correct relationship between RFCs and
>> > reference implementations. An RFC specifies the protocol for a specific
>> I think that the reference implimentation impliments a specific rfc. Ie,
>> the rfc comes first.
> In general you are right. And in this case most people are interested
> in having correct time on their boxes, not a pedantically-correct
> implementation of the RFC.
They also do not care exactly how that is accomplished-- whether via ntp
or chrony say, as long as it is robust and correct.
> And RFCs can be updated. If there is a bug in them people can choose to
> run strictly-compliant broken code or they can apply the fixes.
But there should be difference between a logical bug in the rfc and a
coding bug in the reference implimentation.
> Other folks may choose to value "better timekeeping" and they can have
> what they want, too.
>> > reference implementation. If you do more than fix bugs in the reference
>> > implementation, you need a new RFC before it becomes the standard.
>> An rfc is just a request for comments. It is NOT a standard. It may
>> become one ( although I think none of the ntp rfcs have actually ever
>> become standards).
> NTPv2 was a standard.
More information about the questions