[ntpwg] mode 6 packets and the system status word

[Harlan Stenn]

Dave,

You and I are talking past each other.

This mailing list is a perfectly acceptable place to talk about these
issues.

I don't care which *document* produced by the WG addresses the
monitoring/quality issues.

IMO there *MUST* be a way to clearly ask for a "health/state" report
from an NTP instance and get "useful" information returned.

I think the big hairy problems are:

- People have some degree of clarity of what they (think they) want to ask
- "what they ask for" and "what they actually want" match up to
  different degrees
- It can be Really Painful to figure out what to ask for
- It can be Really Difficult to understand what the 'answers' are (not)
  telling us

I believe it would help a great deal if we could formulate some basic
questions and show how to get those answers and understand *exactly*
what is (and is not) being asked/answered.

My next message should cover this point better.

H
--
> 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
> >
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg