[ntp:questions] WARNING: someone's faking a leap second tonight

Harlan Stenn stenn at ntp.org
Mon Aug 6 06:19:10 UTC 2012


unruh writes:
> 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
> > perspective.
> >
> > 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).

So what?  Any implementation has such freedoms.

> 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.

I don't know.  But have you submitted alleged this list to the RFC
editors?

> 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.

Now you just are being silly.

The code has bugs.

The RFC probably has bugs.

Your email has typos (bugs).

Mine probably does too.

So what?

> The leap second hangs the whole implimentation?  That is as it should
> be.

What are you talking about?  And that was rhetorical, as you're being a
troll and I'm done with this particular interaction after I send this.

> The implimentation does a leapsecond round robin so that it never
> shuts off?  Thatis as it should be.

What are you talking about?  Ibid.

> 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. 

That was better, thanks.

> > 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.

Different perspectives on the issue.  From what I've seen Chrony has its
pros and cons.  But none of this is related to the discussion above, as
best as I can tell.  Unless you want to attempt to assert that chrony is
an NTP reference implementation, which I suspect you are not trying to do.

> > 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.

I don't think you read what I wrote about this.  Please go back and look.
The phrase I used ended with "careful scrutiny and deliberation".

H


More information about the questions mailing list