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

["Ulrich Windl" <[e-mail]>]

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

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

> 
> Regards,
> Brian
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp