[ntpwg] mode 6 packets and the system status word

[David L. Mills]

Harlan,

You have completely missed the point. The stated mission of the WG is to 
produce a separate document on the control and monitoring protocol. 
Presumably, that would be similar to what is now in an appendix to 
rfc1305. Such as this is not appropriate for the base protocol 
specification.

A much more imporant point to make is that whatever protocol does 
develop strictly reflects the statistics presented in the protocol 
specification, NOTHING MORE. The existing NTPv3 monitoring protocol 
makes specific assumptions about the implementation. I am dead set 
against that in the interest of other possible implementations. The 
monitoring protocol MUST NOT make assumptions about the implementation, 
only a framework for reading and writing variables specific to each 
implementation. In other words, the ntpq commands continue to be valid, 
but the billboards returned may differ from one implemtnation to another.

That said, there needs to be a document specific to the current 
reference implementation and there is that in the current documentation. 
See the related pages on status and event decoding and the various 
monitoring options. Note the revised ntpq description. These details DO 
NOT belong in a protocol specification document. You will note that the 
basic mode-6 protocol design is only as a carrier of ASCII text 
information between server and client.

A possibly contentious issue is the interpretation of status words and 
event codes, which are currently implementation dependent. Take a long 
look at decode.html in the current web documentation. Would everybody be 
happy if these data are required for conformance? Note the event codes 
are intended for logging and traps. I gave a lot of thought about the 
status words, but am not sure at all that another implementor would be 
happy with them.

Dave

Harlan Stenn wrote:

> Dave,
>
> I think you are dead wrong in your belief that this is a failed mission,
> but perhaps we have different definitions of "the mission".
>
> And I'm not necessarily talking about the protocol document, unless
> somebody makes the entirely plausible argument that since Figure 10 of
> the specification document says that association mode 6 is an NTP
> control message, we have an obligation to either specify the format and
> content of a mode 6 message in the document or point folks at a
> different document that *does* specify that information.
>
> H
> --
>
>> You have a failed mission. The state codes have nothing to do with the
>> specification document. There might be a connection between what might
>> later be defined with the ntpd monitoring protocol, but that has nothing
>> to do with the specification.
>>
>> Dave
>>
>> Harlan Stenn wrote:
>>
>>> Dave,
>>>
>>> Dave wrote:
>>>
>>>> Surely you know the status words happened to be defined in an appendix
>>>> to rfc1305 and not revelant to the baseline specification.
>>>
>>>
>>> Yes on #1, I don't care on #2, and rfc1305 is about to be obsoleted if I
>>> understand things correctly, and with our almost resolved flap over the
>>> "state" variable I need either a pending or an active RFC that will
>>> address the issue of "how can we determine if an instance of NTP
>>> believes it is 'OK' or not, and exactly what is meant by 'OK'?"
>>>
>>> H
>>> --
>>>
>>>> Harlan Stenn wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> 1305 documents the "system status word" that is returned in the status
>>>>> field of the response to a read status or read variables command 
>>>>> with a
>>>>> zero association identifier.
>>>>>
>>>>> Where are these things specified in the NTPv4 specification?
>>>>>
>>>> _______________________________________________
>>>> ntpwg mailing list
>>>> ntpwg at lists.ntp.org
>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg
>