Subject: [ntpwg] mode 6 packets and the system status word

From: Harlan Stenn <[email-masked]>
Date: Sat, 03 May 2008 07:44:03 +0000

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?

-- 
Harlan Stenn <[email-masked]>
http://ntpforum.isc.org  - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 03 May 2008 16:30:12 +0000

Harlan,

Surely you know the status words happened to be defined in an appendix 
to rfc1305 and not revelant to the baseline specification.

Dave

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 03 May 2008 16:50:30 +0000

Dave,

> 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
--

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 04 May 2008 05:18:23 +0000

Harlan,

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

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 04 May 2008 17:56:33 +0000

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
--

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 04 May 2008 18:38:47 +0000

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

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 04 May 2008 19:17:10 +0000

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
--