Harlan, You make some good points. However, if folks want SNTP from here I think they would prefer it in its own distribution rather than bundle it with the huge NTP distribution. You can make a strong argument to host here if the claim that both NTP and SNTP are strictly specification conformant. That's why I rewrote the SNTP documentation to take out all mention that it could be used as a server.
The three of us that wrote rfc 2030 had just come down from a massive clogging situation at UWisc and NIST and were frantic to get across the need for polite client behavior. This has to do with DNS lookups, poll intervals and behavior when no response is received. Even so, there remains at least three violators of those principles right now on two of our public servers. Therefore, if an SNTP product leaves here, it really and surely should compley with the on-wire protocol in the NTPv4 spec and these best practices. A aside, I should reveal my biases. At the moment, to configure the current software on an Sun Ultra 5 takse 12 minutes, 6 minutes for NTP and 6 minutes for SNTP. But, it takes only 8 minutes to compile and link all programs, including both NTP and SNTP. It is not now possible to build either separately. As I have said privately before, the NTP daemon can be operated in SNTP mode which does everything NTP does, but terminates just after the clock has been set for the first time. Yes, it has a rather large footprint, but it lasts only about 11 seconds. The downside is that it requires a configuration file containing a list of servers. If this were done on the command line, NTP in SNTP mode would be indistinguishable from SNTP other than a command line option. So, the ideal solution would seem to include a list of links on the NTP home page to external sites and in addition internal links to the NTP and SNTP distributions along with a statement that both are strictly specification conformant. That might inspire other wannabees to make and enforce similar claims. Dave Harlan Stenn wrote: >>>>In article <[EMAIL PROTECTED]>, "David L. Mills" <[EMAIL PROTECTED]> writes: > > > David> Harlan, My position on ntpdate and sntp has always been clear. Remove > David> them both from the distribution and let other folks contribute sntp > David> products. > > Yes, your position has been clear and your opinion has been noted. > > David> The standards labs in various contries do not recommend the > David> NTP reference implementation, they recommend other shrinkwrap > David> products. > > I'd appreciate references on this point. And how it is germane to this > discussion? > > David> There is no need for folks to download the reference > David> implementatino only to bring up an sntp product. > > Yes, which is why the sntp code can be trivially bundled separately. > > The feedback I have received is that the majority of folks want the > distribution to contain both ntp and sntp. > > David> The matter of concern is an sntp product that strictly conforms to > David> the NTPv4 specification as it applies to sntp. There is at least one > David> contributor testing the kiss-o'-death rate limit and has apparently > David> actually read rfc 2030. On the other hand, there are numerous > David> examples of clients that casually violate the rate rules both at > David> servers we operate here and at the national labs. > > Yup. > > David> What we should be > David> doing is supporting those products that play by the rules and that > David> are maintained by other players. > > This depends first on the definition of "we", and then on the definition of > "supporting". > > The people who talk to me want an SNTP implementation from the NTP Project. > > Nobody is expecting you to ride herd over any SNTP code that may or may not > be part of the same tarball that includes NTP. I am mulling over different > ideas in this regard. > > Two obvious ways to go on NTP/SNTP are to have shared code, or completely > separate codebases. There is some middle ground regarding "support" > libraries. > > I see difficult tradeoffs with either approach. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
