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

Brian Haberman <brian@innovationslab.net> Wed, 20 September 2017 19:11 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F17132A1A for <ntp@ietfa.amsl.com>; Wed, 20 Sep 2017 12:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu5OmHhewlyV for <ntp@ietfa.amsl.com>; Wed, 20 Sep 2017 12:10:59 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FE3134302 for <ntp@ietf.org>; Wed, 20 Sep 2017 12:10:55 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C2E65880ED for <ntp@ietf.org>; Wed, 20 Sep 2017 12:10:55 -0700 (PDT)
Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 933D53280AE4 for <ntp@ietf.org>; Wed, 20 Sep 2017 12:10:55 -0700 (PDT)
To: "ntp@ietf.org" <ntp@ietf.org>
References: <d5a5ba98-65f2-f2e0-a0ec-40114213fc03@innovationslab.net> <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>
From: Brian Haberman <brian@innovationslab.net>
Message-ID: <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>
Date: Wed, 20 Sep 2017 15:10:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="eBqR7rM0bpOI61sj5hMGnJtHOEWv7g8VK"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/w4Q4anANDTBAWSvqPQA8143QfI8>
Subject: Re: [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2017 19:11:01 -0000


On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>> Brian Haberman <brian@innovationslab.net> schrieb am 18.09.2017 um 19:10 in
> Nachricht <d5a5ba98-65f2-f2e0-a0ec-40114213fc03@innovationslab.net>:
>> 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?

Brian