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

[Brian Haberman <[e-mail]>]

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

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

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

>From Section 2 of the draft:

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

Regards,
Brian