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

[Harlan Stenn <[e-mail]>]

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.

H
--
> 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!
> 
> 
> 
> 
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!