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

[Brian Haberman <[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?

Regards,
Brian