ntpclient sanity checks

[Mihai Buha]

> However, under some circumstances this is a non-compatible 
> change relative
> to previous ntpclient versions, as I discovered trying to connect to a
> badly maintained (by me) time server.

If the incompatibility appears only when communicating with badly
maintained time servers, then it's a Good Thing! The goal of NTP
is to get accurate time, and well maintained servers presumably give
better time than badly maintained ones!

> My question to the group is, should these checks apply 
> optionally (when
> selected with a new command switch), usually (unless deselected with a
> new command switch), or always?

Always! (minus Denis' objections). When people upgrade ntpclient,
they expect it to perform better even (or especially) if this means
rejecting bad servers. If they really want to get shot in the foot
without knowing, they can always use the 2003 version. Of course,
you should document it: "your old scripts should not break, but they
still may, so test them".

> Plus, if a bad packet is received,
> should the server stand mute, or give a warning message (and with what
> level of detail as to how the packet flunked the tests)?

"Bad packet" should be enough, because ntpclient is not a ntp
debugging tool. Please complain loudly about Kiss-of-death packets.
People should not be allowed to abuse ntp servers.

Also, advise people visiting your website to consider using and
joining the ntp pool: www.pool.ntp.org

>     - Larry
Mihai