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

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

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

Regards,
Ulrich



> 
>>> 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 <[e-mail]>
> http://networktimefoundation.org - be a member!