unruh writes: > On 2012-08-04, David Woolley <[email protected]> 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. 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. 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. 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 [email protected] http://lists.ntp.org/listinfo/questions
