Subject: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 31 Aug 2017 13:39:07 +0200

Hello!

I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 to verify my older implementation of NTP control messages.
I found some things that are strange! For example:

(Page 4): "The original development of the NTP daemon included a remote facility (ntpdc) for monitoring and configuration. This facility used mode 7 commands to communicate with the NTP daemon. This document illustrates the mode 7 packet format only.": I thought the document describes mode _6_ packets!?

Similar "The mode 7 message format is shown in Figure 3.: Why describe the packet format then?

While the draft talks about sequence and version numbers in the mode 7 packet, it fails to specify it for mode 6 packets:
"Version Number (VN): This is a three-bit integer indicating a minimum NTP version number. NTP servers do not respond to control messages with an unrecognized version number. Requests may intentionally use a lower version number to enable interoperability with earlier versions of NTP. Responses carry the same version as the corresponding request.": What is the version number the draft specifies? Obviously the first NTP version to support a mode 6 or 7 packet is version 2.
As the definition of the Clock (Radio) Status word is quite different between NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a conforming implementation will handle the VN transmitted in the request packet: Will it respond with the correct packet regarding NV, will it flag obsolete requests as an error (the current implementation does not), or will it always return the current format? ("will" obviously should either "SHOULD" or "MUST" in a specification)

On page 6: "Each request uses a different sequence number.": Is this a recommendation (SHOULD) or a requirement (MUST)? Obviously it should help against spurious packets being received (or for multiple outstanding requests when the order of packets received may vary).

An unanswered issue is how to find out what version the remote party supports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 (for example). Reading variable "version" with a low VN to guess the version will fail on Solaris for example, where the daemon does not return a version string...

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 31 Aug 2017 13:39:07 +0200

Hello!

Regards,
Ulrich

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp