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

[Harlan Stenn <[e-mail]>]

Partial answer: we know the gross version the client wants because it’s in the base packet. 

We’re about to have some interesting discussions.

And I bet they’ll be very similar to the ones we should be having about the Yang Data model, and a reexamination of the NTP SNMP spec. 

Sent from my iPhone. Please excuse brevity and typos.

> On Dec 14, 2017, at 8:45 AM, Brian Haberman <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>