Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 1

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Sep 2017 13:10:37 -0400

Ulrich noted that this document does not specify a version number for
the mode 6 commands. I had suggested specifying it as "version 4 (or
earlier)" given that the introduction of mode 6 commands has occurred at
various versions of the protocol starting at RFC 1305. Ulrich pointed
out that the version number drives the interpretation of the status words.

For people who have implemented or use mode 6 commands, what makes sense
here? Do we need to specify a version number per mode 6 command?

Regards,
Brian

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 18 Sep 2017 16:36:59 -0700

> here? Do we need to specify a version number per mode 6 command?

I've long wanted a way to identify more information about information
about what information is available via mode6 commands, and the format
of that information.

While some of this information is part of the "core", a lot of it is
implementation-specific, and can easily change from one code version to
the next.

I don't think we want to cast any of this into concrete.

On the other hand, we do need a way to figure out what's available
(which may changed based on authorization levels) and the format in
which it's presented.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Sep 2017 08:52:43 +0200

>>> Brian Haberman <[email-masked]> schrieb am 18.09.2017 um 19:10 in
> here? Do we need to specify a version number per mode 6 command?

Hi!

I think there are several issues:

1) Assuming there are different versions (there are!), how can one find out which version the server implements? See 2)

2) if a client requests a version different from the server, what should the server do? The server could respond with a different version number, indicating that it is not willing to respond / privide the information in the format requested. Or the server could respond with a "bad request" status. Finally the server could respond in the format requested... I have slight favor for the first variant unless there is a command to find out what message format versions the server can provide.

3) As it seems to be now, the server ignores the version (versions 2, 3, and 4 all seem to work)

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Sep 2017 09:39:41 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 19.09.2017 um 01:36 in Nachricht

Hi!

"It can", but should it? If you are writing software for yourself, you are free to change it all the time. But if you implement some standard, either stick to the standard, or define a new standard. Arguing that this part is not in the standard does not help anyone. As a matter of fact NTPv3 and NTPv4 return different information for the exactly same command. Obviously that was an oversight when changing things, but that should not repeat, and, if possible, also clean up the past (i.e.: provide a mechanism to get well-specified responses).

> I don't think we want to cast any of this into concrete.

This kind of flexibility on your side causes confusion on the other side.
Let me quote some of my Perl code again (trying to get version independent NTP performance gauges):

        if (!$NTPv4) {
            $vars->set_variable('frequency', $vars->variable('freq') / 1000);
            $vars->set_variable('offset', $vars->variable('phase'));
            $vars->set_variable('noise', $vars->variable('error'));
            $vars->set_variable('jitter', 0);
            $vars->set_variable('stability', '0');
        } else {            # ntpd 4.2.6p2 "introduces" "new" variables
            $vars->copy_variable('rootdispersion', 'rootdisp');
            $vars->copy_variable('noise', 'clk_jitter');
            $vars->copy_variable('jitter', 'sys_jitter');
            $vars->copy_variable('stability', 'clk_wander');
            $vars->copy_variable('poll', 'tc');
            # ntpd 4.2.8 also has new variables
            # "clk_jitter" (CS_ERROR),
            # "ctr_frequency" (Windows: Performance Counter Drift)
        }

So it's hard to get one set of well-defined variables. Don't make it worse!

> (which may changed based on authorization levels) and the format in

Absolutely!

Regards,
Ulrich

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 20 Sep 2017 15:10:53 -0400

> 3) As it seems to be now, the server ignores the version (versions 2, 3, and 4 all seem to work)

The above seems to argue for two things:

1) A preliminary handshake between an NTP server and the mode6-speaking
client to determine what version is in use.

2) A change to the operating basis of the mode 6 commands in that the
above mentioned handshake occurs before actually sending the mode 6 command.

Is that a good representation of what is being asked for?

Brian

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 20 Sep 2017 15:42:23 -0700

> Is that a good representation of what is being asked for?

If it is, I'm thinking we'd want a mode 6 "Identify" command, that would
have this information in a response.  This response would likely contain
different data before/after authentication.

I'd also much rather we had changes to do this that are tested and known
to do what we want instead of codifying what folks hope will be a good
solution.

I'm happy to work with collaborative folks, experienced or not, who want
to dig in to this.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Brian Haberman <[email-masked]>
Date: Thu, 21 Sep 2017 09:23:58 -0400

Hi Harlan,

> I'm happy to work with collaborative folks, experienced or not, who want

This document is controlled by the consensus of the WG. So it is up to
the participants interested in adding such functionality to "drum up the
support" for adding it to the draft.

Regards,
Brian

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 22 Sep 2017 08:02:17 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 21.09.2017 um 00:42 in Nachricht
<[email-masked]>:

>>> 1) Assuming there are different versions (there are!), how can one find out 
> which version the server implements? See 2)
>>>
>>> 2) if a client requests a version different from the server, what should the 
> server do? The server could respond with a different version number, 
> indicating that it is not willing to respond / privide the information in the 
> format requested. Or the server could respond with a "bad request" status. 
> Finally the server could respond in the format requested... I have slight 
> favor for the first variant unless there is a command to find out what 
> message format versions the server can provide.
>>>

Why that? You should elaborate on the role of authentication.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 21 Sep 2017 23:26:42 -0700

> Why that? You should elaborate on the role of authentication.

Here's a short list.

- Nobody but trusted folks should see the origin timestamp of a pending
  symmetric mode exchange.

- Nobody but trusted folks should be able to get the list of our
  potential servers.

- Nobody but VERY trusted folks should be able to issue :config
  directives

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 22 Sep 2017 09:05:26 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 22.09.2017 um 08:26 in Nachricht
<[email-masked]>:

>>>>> 3) As it seems to be now, the server ignores the version (versions 2, 3, and 
> 
>>> 4 all seem to work)
>>>>>
>>>>

Hi Harlan,

even more confused now: The issue was (unless I'm confused) to finde out what mode-6 protocol version the remote side (server) speaks.
You talk about changing the requirements of existing commands (it seems).
I have no objection changing the require ments on the next mode-6 protocol level, but these issues should be clearly separated IMHO.

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 22 Sep 2017 00:47:11 -0700

> I have no objection changing the require ments on the next mode-6 protocol level, but these issues should be clearly separated IMHO.

I thought the intent was to make sure that ntpq could ask an NTP server
"what can you tell me about yourself?", in enough detail that the client
will then know what to ask, and how to interpret the results.

H
--