[ntpwg] exposed data

[David L. Mills]

Harlan,

The mode-6 protocol itself is not an issue; it just reveals what the 
server sends. The ntpq program, which just lights up what is revealled 
by the server, is not an issue. The ntpq program should never reveal 
data on its own, which is why the flash decodes are so contentious. 
These decodes use local interpretation which can be at odds with the 
documentation and server design. This violates my original design which 
required using only the data the server sends. If decodes are needed, 
the server should send them.

The ntpq program, protocol and server revelations were never intended to 
be standardized. The program was and is used as a diagnostic, the 
details of which can be adjusted and/or expanded from time to time, 
especailly as new features like orphan and Autokey are implemnted and 
tested. The program should be flexible and usable, even with warts.

Your mission has absolutely no legs in the context of the protocol, ntpq 
or revealled informatio. It has absolultely brilliant legs for the MIB 
mission and should be seriously discussed in that context.

Dave

Harlan Stenn wrote:

> ntpd can expose a fair bit of information about its state.
>
> The mode 6 packets can do a lot of this already.
>
> In the reference implementation, ntpq (which uses mode 6 packets, as
> opposed to ntpdc, which uses mode 7 packets) can expose a fair amount of
> data.
>
> Some of this data is arguably generic information that would be 
> implemented
> by anybody doing an NTP implementation, and some of this data is arguably
> implementation-specific data.
>
> To what extent should we identify where on the continuum between
> "implementation-specific" and "MUST implement" the bits of data exposed by
> the reference implementation fall?
>
> To what extent should the mode 6 protocol "handle" these various bits of
> data?
>
> At what, if any, point do we want to standardize any of these items?
>
> I know I am asking some questions that have been already addressed, at 
> least
> in some way.
>
> It just seems to me that we haven't achieved any useful resolution on this
> topic, at least based on the several open reports I have in my ntp 
> bugzilla
> queue.
>
> I'm also not suggesting we resolve these points before the V4 spec is
> finalized. But I do believe we must address and resolve this issue.