[ntpwg] Re: [ntp:hackers] Re: peer flash bits

[David L. Mills]

Harlan,

A basic design decision in 1982 and continued to this day was to keep 
the daemon clean and uncluttered with explanatory material such as tool 
tips and leave such things to the utilities. There is absolutely no 
wiggle room in this area. Another basic design decision was that the 
prettyprint ASCII could be read by a very simple UDP program, even if it 
requires occasional reference to the spec and possibly the sources for 
non-spec items (e.g., flasher commentary in ntp.h). I submit this 
approach is completely tenable and has been for the life of the protocol 
and five evolved implementations.

Don't get going on this; it is a nonstarter and I'm not going to add to 
the already intimidating body of work to produce the spec. The spec 
describes the state machines, variables, constants, algorithms, formats 
and protocols. The control and monitoring protocol is not an integral 
component of the NTPv4 protocol spec itself and I am not going to change 
it in any way. While some effort has been made to relate the prettyprint 
external names to the internal state variables, those external names are 
not defined in the spec.

If you can work with the above rules, I would very much like to see ntpq 
and ntpdc reconsidered and reworked. We've talked about this before.

Dave

Harlan Stenn wrote:

>Dave,
>
>
>>The ntpd doesn't return anything except raw status bits and raw 
>>vegetables. It does no interpret the bits or provide flash tool tips. 
>>
>
>If you don't understand why this is untenable then let's agree to
>disagree and I'll do whatever I can to fix the problem.
>
>
>>That's the function of ntpq in whatever form.
>>
>
>ntpq cannot possibly do this job under the present circumstances.
>
>
>>Can we go beyond the flasher issue, which is not a specification
>>issue? 
>>
>
>Anybody can focus on whatever they choose.
>
>I'm gonna fix this problem, along with whatever other problems I can
>work on.
>
>H
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://support.ntp.org/mailman/private/ntpwg/attachments/20050314/7095f9f9/attachment.html