IETF Logo Mail Archive

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

Brian Haberman <brian@innovationslab.net> Mon, 18 September 2017 17:10 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 D75921342C7 for <ntp@ietfa.amsl.com>; Mon, 18 Sep 2017 10:10:39 -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 FgwS8xjq6xUl for <ntp@ietfa.amsl.com>; Mon, 18 Sep 2017 10:10:38 -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 CB97B1342BE for <ntp@ietf.org>; Mon, 18 Sep 2017 10:10:38 -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 C152D88129 for <ntp@ietf.org>; Mon, 18 Sep 2017 10:10:38 -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 8BAD03280AE4 for <ntp@ietf.org>; Mon, 18 Sep 2017 10:10:38 -0700 (PDT)
To: ntp@ietf.org
From: Brian Haberman <brian@innovationslab.net>
Message-ID: <d5a5ba98-65f2-f2e0-a0ec-40114213fc03@innovationslab.net>
Date: Mon, 18 Sep 2017 13:10:37 -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
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="B4RTHBSxWOUW5x80EqPGCATestA3VRSf4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/deT5zqknpeyAZUrK_beo44ZZke0>
Subject: [Ntp] 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: Mon, 18 Sep 2017 17:10:40 -0000

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?

Regards,
Brian

v2.23.0 | Report a Bug | By Email