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

From: Brian Haberman <[email-masked]>
Date: Thu, 14 Dec 2017 11:45:53 -0500

Reviving this thread because we never reached any consensus on what
things we want in the mode-6-cmds draft...

On 9/22/17 3:47 AM, Harlan Stenn wrote:
> 
> 
> On 9/22/2017 12:05 AM, Ulrich Windl wrote:
>>>>> Harlan Stenn <[email-masked]> schrieb am 22.09.2017 um 08:26 in Nachricht
>> <[email-masked]>:
>>
>>> On 9/21/17 11:02 PM, Ulrich Windl wrote:
>>>>>>> Harlan Stenn <[email-masked]> schrieb am 21.09.2017 um 00:42 in Nachricht
>>>> <[email-masked]>:
>>>>
>>>>>
>>>>> On 9/20/17 12:10 PM, Brian Haberman wrote:
>>>>>>
>>>>>>
>>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>>>>>>>> Brian Haberman <[email-masked]> schrieb am 18.09.2017 um 19:10 in
>>>>>>> Nachricht <[email-masked]>:
>>>>>>>> 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?
>>>>>>>
>>>>>>> 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)
>>>>>>>
>>>>>>
>>>>>> 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?
>>>>>
>>>>> 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.
>>>>
>>>> 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
>>
>> 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.
> 
> 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.

I can interpret this capability in two ways:

1. ntpq tells the server what version it is going to ask its questions
for. This is based on Ulrich's example code showing that different
variables exist in different versions. The response back from the server
would be a binary (Y/N) on its ability to answer questions for that version.

2. ntpq asks the server which version(s) it supports. When the server
responds with a version number, ntpq figures out whether it can handle
questions for that version.

I interpret Harlan's response as an indication that he thinks option 2
is the way to go. If that is the case, it would seem that we would want
to add a new command to the draft that asks the server to indicate its
version of NTP.

Other thoughts?

Regards,
Brian

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 14 Dec 2017 13:48:27 -0800

Partial answer: we know the gross version the client wants because it’s in the base packet. 

We’re about to have some interesting discussions.

And I bet they’ll be very similar to the ones we should be having about the Yang Data model, and a reexamination of the NTP SNMP spec. 

Sent from my iPhone. Please excuse brevity and typos.

> On Dec 14, 2017, at 8:45 AM, Brian Haberman <[email-masked]> wrote:
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 18 Dec 2017 09:20:13 +0100

>>> Brian Haberman <[email-masked]> schrieb am 14.12.2017 um 17:45 in
Nachricht <[email-masked]>:
>>> even more confused now: The issue was (unless I'm confused) to finde out 
> what mode-6 protocol version the remote side (server) speaks.
>>> I have no objection changing the require ments on the next mode-6 protocol 
> level, but these issues should be clearly separated IMHO.
>> 

Hi!

Variant 1 would require a different interpretation of existing commands (i.e.: consider the incoming version number), while variant 2 just adds one additional command, leaving others alone.

Maybe consider how a more modern protocol like IPP (see RFC 8011, section 4.1.8) handles that (in a nutshell):
The client sends an expected version number: If the server supports it, everything is fine; if not the server also tells the client what the supported version numbers are. In addition every answer from the server consideres the version number requested by the client.

I think the most important issue about all that is that any change to the result message (like new or removed variable names) MUST change the version number.

The other question is whether this version number is the NTP protocol version number (VN), or some new variable like "mode-6-protocol-version" (or anything shorter).

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 18 Dec 2017 00:26:01 -0800

I'm pretty sure we're going to need a "mode 6" version, and we're also
going to need to decide about "standard" contents and "vendor-specific"
contents.

We're going to need this for the Yang stuff, too.

H

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

---

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Dec 2017 08:11:32 -0500

> Variant 1 would require a different interpretation of existing commands (i.e.: consider the incoming version number), while variant 2 just adds one additional command, leaving others alone.

I asked the above questions the way I did based on my interpretation of
what this draft is trying to accomplish. There have been numerous
complaints that the mode 6 commands were lost when RFC 1305 was made
obsolete when 5905 was published without carrying the mode 6 commands
forward. This document is supposed to be the informational reference for
the existing mode 6 commands.

>From the abstract of the draft:

The goal of this document is to provide a historic description of the
control messages.

I certainly don't see WG consensus to change the focus of this document
from a historical documentation exercise to a re-definition of mode 6...

>From Section 2 of the draft:

Version Number (VN): This is a three-bit integer indicating a minimum
NTP version number.

Regards,
Brian

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 18 Dec 2017 23:44:07 -0800

> the existing mode 6 commands.

OK.  I asked that mode 6 be added back in because it's something that's
been in active use to monitor and manage NTP instances for over 20
years' time.

> from a historical documentation exercise to a re-definition of mode 6...

Since the reference implementation has been doing mode 6 for a very long
time, there's little value to me in documenting historical behavior in
an RFC.

I do think there is value in an RFC that describes current practice,
that is also used for any current changes.  This is the base information
that a conforming implementation would use to implement RFC5907 (the
SNMP mapping) and the Yang data model stuff.

I'll even go one better and suggest that we should have a list of common
pieces of information that SHOULD/MUST be implemented, perhaps a list of
items that MAY be implemented, and a means to map these to mode 6, SNMP
and Yang.  There also needs to be a way to deal with
implementation-specific data.

Without this level of detail, there won't be a useful or easy way to
have a monitoring/management tool talk with an NTP instance in anything
other than an implementation-specific way.

> Version Number (VN): This is a three-bit integer indicating a minimum

That's the NTP Protocol version, and isn't particularly useful for this.
 We've already seen the v4 ntpq change from reporting dispersion to
reporting jitter.  We've seen changes in some other values, too.

It seems to me the value in this work is so folks can write tools to
monitor and manage their NTP instances, and that gets lots easier if the
API and values are documented.