On 2012-08-04, Harlan Stenn <st...@ntp.org> wrote: > unruh writes: >> On 2012-08-04, David Woolley <david@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). 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. > > H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
