>>> In article <[email protected]>, Joseph Gwinn >>> <[email protected]> writes:
Joseph> In article <[email protected]>, Joseph> Harlan Stenn <[email protected]> wrote: >> >>> In article <[email protected]>, Joseph >> >>> Gwinn <[email protected]> writes: >> >> >> I think you are talking about one of my pet peeves: >> >> >> >> http://support.ntp.org/bin/view/Dev/NtpVariablesAndNtpq Joseph> I don't think that I have inconsistent versions of ntpd and ntpq, Joseph> because both came off the same CD from Sun Microsystems. >> It's still the same beast. The bottom line is we currently have opaque >> data being presented to the user, and that is either being offered >> directly to the user (in your case) or is being potentially mis-converted >> by ntpq. Joseph> I have a lot of trouble believing that Sun put inconsistent versions Joseph> on their Solaris install CDs. I was not talking about the inconsistent version problem. I'm talking about opaque data. Joseph> Nor am I using NTPQ for decoding. I decode these codes myself, Joseph> following Appendix B of RFC-1305. It turns out that NTPv4 uses the Joseph> same definitions. See Joseph> <http://www.eecis.udel.edu/~mills/ntp/html/monopt.html>. Then I may have misunderstood. My point is that while it's fine for ntpd to send "encoded data", I think we need to have a way for that data to *also* be sent decoded, or provide enough information so programs like ntpq can decode the result, regardless of which version of ntpd they are talking to. -- Harlan Stenn <[email protected]> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
