From nobody Mon Dec 4 21:39:21 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8665124B18; Mon, 4 Dec 2017 21:39:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151245235284.13882.9522986234259479107@ietfa.amsl.com> Date: Mon, 04 Dec 2017 21:39:12 -0800 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-refid-updates-02.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 05:39:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Network Time Protocol REFID Updates Authors : Harlan Stenn Sharon Goldberg Filename : draft-ietf-ntp-refid-updates-02.txt Pages : 11 Date : 2017-12-04 Abstract: RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines the value of the REFID, the system peer for the responding host. In the past, for IPv4 associations the IPv4 address is used, and for IPv6 associations the first four octets of the MD5 hash of the IPv6 are used. There are at least three shortcomings to this approach, and this proposal will address the three so noted. One is that knowledge of the system peer is "abusable" information and should not be generally available. The second is that the four octet hash of the IPv6 address looks very much like an IPv4 address, and this is confusing. The third is that a growing number of low-stratum servers want to offer leap-smeared time to their clients, and there is no obvious way to know if a server is offering accurate time or leap- smeared time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-refid-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-refid-updates-02 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-refid-updates-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-refid-updates-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 11 05:32:14 2017 Return-Path: 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 BEEA0126CD8 for ; Mon, 11 Dec 2017 05:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de 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 gP8qz3BuVLVH for ; Mon, 11 Dec 2017 05:32:10 -0800 (PST) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E26012422F for ; Mon, 11 Dec 2017 05:32:09 -0800 (PST) Received: from srv-kerioconnect.py.meinberg.de (unknown [217.6.112.194]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id CC06671C0B18 for ; Mon, 11 Dec 2017 14:32:04 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de CC06671C0B18 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1512999127; bh=78mOkLcZTV12yIQrJ6Pk5k25hxoEINh8EKK3j3gWHPQ=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Btxu8LEzf/0ypb9iLdzzEA4AyoSwwzpImPoigawHqFmvisgwH5ffK5SZc7TydqvVc uBSAslBsUZUynRekgYwD7kUY/UG4djuPRN2kQkIJE3XsR3ArexNXttw7p4clqUVZ6R AfyrKw7TH347G1qVK0SXkNxwSuiQKtOm0UZQ1z+c= X-Kerio-Anti-Spam: Build: [Engines: 2.15.8.1136, Stamp: 3], Multi: [Enabled, t: (0.000006,0.003002)], BW: [Enabled, t: (0.000007)], RTDA: [Enabled, t: (0.725547), Hit: No, Details: v2.6.15; Id: 15.5f4705.1c0cclrop.9gmd1], total: 0(700) X-Footer: bWVpbmJlcmcuZGU= Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for ntp@ietf.org; Mon, 11 Dec 2017 14:31:51 +0100 To: ntp@ietf.org References: <20171002133817.GA30411@localhost> <59E4603E020000A1000285FC@gwsmtp1.uni-regensburg.de> From: Martin Burnicki Organization: Meinberg Funkuhren, Bad Pyrmont, Germany Message-ID: Date: Mon, 11 Dec 2017 14:31:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at server1a X-Virus-Status: Clean Archived-At: Subject: Re: [Ntp] Antw: Re: Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 13:32:13 -0000 Folks, sorry for jumping in so late. I just read RFC-7822 https://tools.ietf.org/html/rfc7822 as well as Harlan's proposal for a replacement of that RFC https://github.com/hstenn/ietf-ntp-extension-field.git IMO Harlan's proposal is very detailed and profound, and provides the reader with quite a bit of information about potential pitfalls in implementations. It also sounds like it's backward compatible with existing NTP implementations, which is very important, and on the other hand pretty flexible. Harlan, is there an implementation of this proposal which has been or can be tested in real operation? Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 (0)5281 9309-14 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy From nobody Mon Dec 11 12:22:09 2017 Return-Path: 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 E32891274A5 for ; Mon, 11 Dec 2017 12:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 oUwHNFR-52TW for ; Mon, 11 Dec 2017 12:22:06 -0800 (PST) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266761273B1 for ; Mon, 11 Dec 2017 12:22:06 -0800 (PST) Received: from hms-mbp11.pfcs.com (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 5AE4FB837; Mon, 11 Dec 2017 20:22:05 +0000 (UTC) To: Martin Burnicki , ntp@ietf.org References: <20171002133817.GA30411@localhost> <59E4603E020000A1000285FC@gwsmtp1.uni-regensburg.de> From: Harlan Stenn Message-ID: <7f260d89-9d95-37d1-27da-15583ffc5f76@nwtime.org> Date: Mon, 11 Dec 2017 12:22:03 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ntp] Antw: Re: Updates to draft-stenn-ntp-extension-fields X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 20:22:08 -0000 On 12/11/17 5:31 AM, Martin Burnicki wrote: > Folks, > > sorry for jumping in so late. > > I just read RFC-7822 > https://tools.ietf.org/html/rfc7822 > > as well as Harlan's proposal for a replacement of that RFC > https://github.com/hstenn/ietf-ntp-extension-field.git > > IMO Harlan's proposal is very detailed and profound, and provides the > reader with quite a bit of information about potential pitfalls in > implementations. > > It also sounds like it's backward compatible with existing NTP > implementations, which is very important, and on the other hand pretty > flexible. > > Harlan, > > is there an implementation of this proposal which has been or can be > tested in real operation? Thanks for the feedback, Martin! Yes, I've been running an implementation of this for several/many months' time. This code will likely be published in January. -- Harlan Stenn http://networktimefoundation.org - be a member! From nobody Tue Dec 12 07:58:08 2017 Return-Path: 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 42BEF1294B2; Tue, 12 Dec 2017 07:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 hHVZDeRCcllc; Tue, 12 Dec 2017 07:58:00 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0080.outbound.protection.outlook.com [104.47.41.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F371294A3; Tue, 12 Dec 2017 07:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wxM8zMGlbShMkVigc1lUDb5g/5gAGOFq4ZfUsZk5Uz4=; b=ZuIM6gwrzvo5FiTedCKYTUuWLev5puVE++bkbBX8FfGi32ChzxK8OqaD3dMLtzFFHG8J2FtYQGKc+TQxvfM+k4tlaPk/jAjDuiJo4i0FWeWH1Um2fFwD57+rus0t8flPCOLpP8DZ40fPCWdfPv6vm5uTK1F6w700RyaiPwnMWxU= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2455.namprd06.prod.outlook.com (10.169.186.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 12 Dec 2017 15:57:57 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0302.014; Tue, 12 Dec 2017 15:57:57 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" , "tictoc@ietf.org" Thread-Topic: Reminder: NTP/TICTOC working group meeting today (in one hour) Thread-Index: AQHTc2H6ByIamYowKUK3TG3nmVmPzw== Date: Tue, 12 Dec 2017 15:57:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-originating-ip: [173.44.72.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2455; 6:wPX/+V+FNghsX1kDwk4c2RPp52xEC8KkfmzhnvElqSotEVd8ZLhrfDoR/VrSrhclLB7iYJAfR0MQzOVW4zd9fdcGnP0PeXMj642ttarhkNnfHRGsvSUyUS5d4nCfQxpm1IYBs411o9+QeX0OzbDYmhW+pV2ADG8N6P5IdtYf24qlafd8mOfMuWdD9EMn5UXNP8V16sZXzlCQ6L8mD4OM6UA5GvuG0qBSILjzUIMs8m22GkFZpncWEfXExNMMRq/nGduSVpCPlV72pQdFfWPL/ShVMPIVFC6irGnCKXq5xwKzwAipJ4E9/hCGdeNctHcN6uyLQtgm7tPStkXNfEOZbmZ1vXC8F/yPRf/OUcNfOAs=; 5:q1ENPWEjvGZzk92tOY2g+pFaAT9icGocyoBRx6hjCoPGZwgtIjSw9ulWq1+WudO2ZyLC4NIPkTbTWVVOZ6UuEs6Yz0Vp1ujKClIFgfbnOfaIISmrPmEIc9i+pzEoIpq+dXWn6ouA9bsZoSHoV0ODh9CJu5YIkoPcZwtiCylUxCY=; 24:LScqQl3BTEgrYCDdGiQu/ss/iwLnFRVjXrpIFrKnm9RxmEg00VMuJgwwNFYbB1XsuTDLsVDCDZ+LJ241ZuZ4Uz5G11bXJ0nQdVKFCy5jzTg=; 7:JHjCD8at3SToKwJXtUQZpYZ7PRerJP2IhWlM/rPTSaDeUJa7qKjM0F9sNloxwhD9m9XVkhV0WYS329PzT9y/NvRgGQjht9qh3z6DxMwMO5+pvBDoWmfhWl6hnPewrA4lITrm2n9itxwRZ8lCG+jamQWSEPwP6nI4p+SRPu51vNgtqyWJwTMSwfzvlWEfU5TemRZ9MXDhZ4BsOg5jqPWJObHirO1JECqJ4l236micqVLEPqgvTmfibpqay8adlWfa x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 452f4a4a-8ca2-4134-67c4-08d541791d0f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:CY4PR06MB2455; x-ms-traffictypediagnostic: CY4PR06MB2455: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(257447070540367); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231023)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:CY4PR06MB2455; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR06MB2455; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(189003)(199004)(497574002)(12213003)(14454004)(3660700001)(33656002)(5660300001)(66066001)(2906002)(3280700002)(97736004)(83716003)(316002)(59450400001)(110136005)(8936002)(36756003)(99286004)(6306002)(6436002)(6116002)(3846002)(102836003)(7736002)(6506006)(6512007)(6486002)(82746002)(25786009)(450100002)(2900100001)(305945005)(68736007)(53936002)(77096006)(81156014)(966005)(86362001)(8676002)(81166006)(2501003)(105586002)(478600001)(106356001)(166863002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2455; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <691797967AC0D64BAB2730D2A3A271DF@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 452f4a4a-8ca2-4134-67c4-08d541791d0f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 15:57:57.6096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2455 Archived-At: Subject: [Ntp] Reminder: NTP/TICTOC working group meeting today (in one hour) X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 15:58:02 -0000 Rm9sa3MsDQoNClRoaXMgaXMganVzdCBhIHF1aWNrIHJlbWluZGVyIHRoYXQgdGhlcmUgaXMgYW4g TlRQL1RJQ1RPQyBpbnRlcmltIG1lZXRpbmcgaW4gb25lIGhvdXIuIEJlbG93IGlzIGFuIHVwZGF0 ZWQgYWdlbmRhIGFuZCB6b29tIGNhbGwgZGV0YWlsc+KApg0KDQpLYXJlbg0KDQpKb2ludCBOVFAv VElDVE9DIFZpcnR1YWwgSW50ZXJpbSBXRyBNZWV0aW5nDQpUdWVzZGF5LCAxMiBEZWNlbWJlciAy MDE3LCAxNzowMCAtIDE4OjMwIFVUQyANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KDQooWm9vbSBkZXRhaWxzIGJlbG93KQ0KDQoxLiBBZG1pbmlzdHJhdGl2 ZSBhbmQgQWdlbmRhIEJhc2hpbmcgKENoYWlycykgDQoNCk5UUCBXRyBBZ2VuZGE6DQo9PT09PT09 PT09PT09PQ0KDQoyLiBOZXR3b3JrIFRpbWUgU2VjdXJpdHkgDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwDQoNCjMu IE5UUCBJbnRlcmxlYXZlZCBNb2RlcyANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtbWxpY2h2YXItbnRwLWludGVybGVhdmVkLW1vZGVzDQoNCjQuIE5UUCBFeHRl bnNpb24gRmllbGRzDQoNCk5ldHdvcmsgVGltZSBQcm90b2NvbCBWZXJzaW9uIDQgKE5UUHY0KSBF eHRlbnNpb24gRmllbGRzIA0KZHJhZnQtc3Rlbm4tbnRwLWV4dGVuc2lvbi1maWVsZHMtMDQgDQoN Ck5ldHdvcmsgVGltZSBQcm90b2NvbCBFeHRlbmRlZCBJbmZvcm1hdGlvbiBFeHRlbnNpb24gRmll bGQgDQpkcmFmdC1zdGVubi1udHAtZXh0ZW5kZWQtaW5mb3JtYXRpb24tMDEgDQoNCk5ldHdvcmsg VGltZSBQcm90b2NvbCBJLURvIEV4dGVuc2lvbiBGaWVsZCANCmRyYWZ0LXN0ZW5uLW50cC1pLWRv LTAzIA0KDQpOZXR3b3JrIFRpbWUgUHJvdG9jb2wgTUFDL0xhc3QgRXh0ZW5zaW9uIEZpZWxkcyAN CmRyYWZ0LXN0ZW5uLW50cC1tYWMtbGFzdC1lZi0wMSANCg0KTmV0d29yayBUaW1lIFByb3RvY29s IFN1Z2dlc3QgUkVGSUQgRXh0ZW5zaW9uIEZpZWxkIA0KZHJhZnQtc3Rlbm4tbnRwLXN1Z2dlc3Qt cmVmaWQtMDIgDQoNCk5UUCBDb3JyZWN0aW9uIEZpZWxkIA0KZHJhZnQtbWxpY2h2YXItbnRwLWNv cnJlY3Rpb24tZmllbGQtMDEgDQoNCjUuIE5ldHdvcmsgVGltZSBQcm90b2NvbCBSRUZJRCBVcGRh dGVzDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC1yZWZp ZC11cGRhdGVzLw0KDQo2LiBPcGVuIHdvcmsgaXRlbXMgKE5vIHVwZGF0ZXMgc2luY2UgSUVURiAx MDApOiANCg0KTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIGZvciB0aGUgTmV0d29yayBUaW1l IFByb3RvY29sDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtbnRwLW1hYw0KDQpOVFAgQ2xpZW50IERhdGEgTWluaW1pemF0aW9uDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbnRwLWRhdGEtbWluaW1pemF0aW9u DQoNCk5UUCBCQ1ANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1udHAtYmNwDQoNCkEgWUFORyBEYXRhIE1vZGVsIGZvciBOVFANCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1udHAteWFuZy1kYXRhLW1vZGVsDQoN Ckd1aWRlbGluZXMgZm9yIERlZmluaW5nIFBhY2tldCBUaW1lc3RhbXBzIChNaXpyYWhpKQ0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1taXpyYWhpLWludGFyZWEt cGFja2V0LXRpbWVzdGFtcHMvDQoNCk9uIEltcGxlbWVudGluZyBUaW1lDQpkcmFmdC1hYW5jaGFs LXRpbWUtaW1wbGVtZW50YXRpb24tZ3VpZGFuY2UtMDANCg0KDQpUSUNUT0MgQWdlbmRhOg0KPT09 PT09PT09PT09PT0NCg0KNy4gT3BlbiB3b3JrIGl0ZW1zIChObyB1cGRhdGVzIHNpbmNlIElFVEYg MTAwKTogDQoNCklFRUUgMTU4OCBFbnRlcnByaXNlIFByb2ZpbGUNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRpY3RvYy1wdHAtZW50ZXJwcmlzZS1wcm9maWxlDQoNCllB TkcgZGF0YSBtb2RlbCBmb3IgSUVFRSAxNTg4djINCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcNCg0KOC4gQU9CIA0KDQoN Clpvb20gZGV0YWlsczogDQo9PT09PT09PT09PT09DQpUb3BpYzogTlRQL1RJQ1RPQyB2aXJ0dWFs IGludGVyaW0gDQpUaW1lOiBEZWMgMTIsIDIwMTcgMTI6MDAgUE0gRWFzdGVybiBUaW1lIChVUyBh bmQgQ2FuYWRhKQ0KDQpKb2luIGZyb20gUEMsIE1hYywgTGludXgsIGlPUyBvciBBbmRyb2lkOiBo dHRwczovL2lzb2Muem9vbS51cy9qLzQ0Mzk3MDYxNg0KDQpPciBpUGhvbmUgb25lLXRhcCA6DQog ICAgVVM6ICsxNjQ2NTU4ODY1NiwsNDQzOTcwNjE2IyAgb3IgKzE2Njk5MDA2ODMzLCw0NDM5NzA2 MTYjIA0KT3IgVGVsZXBob25lOg0KICAgIERpYWwoZm9yIGhpZ2hlciBxdWFsaXR5LCBkaWFsIGEg bnVtYmVyIGJhc2VkIG9uIHlvdXIgY3VycmVudCBsb2NhdGlvbinvvJoNCiAgICAgICAgVVM6ICsx IDY0NiA1NTggODY1NiAgb3IgKzEgNjY5IDkwMCA2ODMzIA0KICAgIE1lZXRpbmcgSUQ6IDQ0MyA5 NzAgNjE2DQogICAgSW50ZXJuYXRpb25hbCBudW1iZXJzIGF2YWlsYWJsZTogaHR0cHM6Ly9pc29j Lnpvb20udXMvem9vbWNvbmZlcmVuY2U/bT1pVnVhMTZwMDA3ZmdtWWlBb2o3Mld3cUpjdXZRRlpE Tw0KDQpPciBhbiBILjMyMy9TSVAgcm9vbSBzeXN0ZW06DQogICAgSC4zMjM6IA0KICAgICAgICAx NjIuMjU1LjM3LjExIChVUyBXZXN0KQ0KICAgICAgICAxNjIuMjU1LjM2LjExIChVUyBFYXN0KQ0K ICAgICAgICAyMjEuMTIyLjg4LjE5NSAoQ2hpbmEpDQogICAgICAgIDExNS4xMTQuMTMxLjcgKElu ZGlhKQ0KICAgICAgICAyMTMuMTkuMTQ0LjExMCAoRU1FQSkNCiAgICAgICAgMjAyLjE3Ny4yMDcu MTU4IChBdXN0cmFsaWEpDQogICAgICAgIDIwOS45LjIxMS4xMTAgKEhvbmcgS29uZykNCiAgICAg ICAgNjQuMjExLjE0NC4xNjAgKEJyYXppbCkNCiAgICAgICAgNjkuMTc0LjU3LjE2MCAoQ2FuYWRh KQ0KICAgIE1lZXRpbmcgSUQ6IDQ0MyA5NzAgNjE2DQoNCiAgICBTSVA6IDQ0Mzk3MDYxNkB6b29t Y3JjLmNvbQ0KDQo= From nobody Tue Dec 12 09:04:18 2017 Return-Path: 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 EE8ED1294CF for ; Tue, 12 Dec 2017 09:04:16 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 4Ki8vt5_65Oz for ; Tue, 12 Dec 2017 09:04:15 -0800 (PST) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169AE1294CE for ; Tue, 12 Dec 2017 09:04:15 -0800 (PST) Received: from hms-mbp11.pfcs.com (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4B4C5B837; Tue, 12 Dec 2017 17:04:14 +0000 (UTC) References: <24e2b242-f010-d1fb-4459-a76d530b37ac@t-online.de> To: "ntp@ietf.org" From: Harlan Stenn X-Forwarded-Message-Id: <24e2b242-f010-d1fb-4459-a76d530b37ac@t-online.de> Message-ID: <1ff6200e-3d6b-7eb7-573f-f353d8888536@nwtime.org> Date: Tue, 12 Dec 2017 09:04:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <24e2b242-f010-d1fb-4459-a76d530b37ac@t-online.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ntp] Fwd: Re: ietf-ntp-extension-field document X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 17:04:17 -0000 Juergen said he sent this to the list about 11 hours' ago, but I didn't see it. Here's what he sent me. -------- Forwarded Message -------- Return-Path: X-Original-To: stenn@nwtime.org Delivered-To: stenn@nwtime.org Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id 573F0B864 for ; Mon, 11 Dec 2017 18:58:42 +0000 (UTC) Received: from mailout01.t-online.de (mailout01.t-online.de [194.25.134.80]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPS id B3A0DB837 for ; Mon, 11 Dec 2017 18:58:41 +0000 (UTC) Received: from fwd24.aul.t-online.de (fwd24.aul.t-online.de [172.20.26.129]) by mailout01.t-online.de (Postfix) with SMTP id 8483B42E4280 for ; Mon, 11 Dec 2017 19:58:39 +0100 (CET) Received: from [192.168.1.11] (Vgg5KvZJZh4-c8JQpBsTxcbo41unGRk+hRSn5k7nSIWyinM2IySMfsCxuu39JDSQC7@[217.81.146.20]) by fwd24.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1eOTHi-0pEs1g0; Mon, 11 Dec 2017 19:58:38 +0100 Subject: Re: ietf-ntp-extension-field document To: Harlan Stenn References: <3b623814-77cb-7019-438a-77e785632b96@nwtime.org> From: juergen perlinger Message-ID: <24e2b242-f010-d1fb-4459-a76d530b37ac@t-online.de> Date: Mon, 11 Dec 2017 19:58:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3b623814-77cb-7019-438a-77e785632b96@nwtime.org> Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="QX8JtU5rrQhV5Tfg0d44kTKmKFAlsV4jE" X-ID: Vgg5KvZJZh4-c8JQpBsTxcbo41unGRk+hRSn5k7nSIWyinM2IySMfsCxuu39JDSQC7 X-TOI-MSGID: 570a02aa-8c6b-4f87-a6cd-e58d5fdd5b3b X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Dec 11 18:58:42 2017 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 3974,5a2ed56213612127916444 Hello Harlan! I finally found the time to read through the proposal and rfc7822. First, to disambiguate an EF from a legacy MAC by requiring the MAC (+ key identifier) be <= 24 bytes and all extension fields > 24 bytes (which effectively becomes >= 28 under the alignment rule) is bad for the reasons you stated: Making longer hashes impossible, and causing waste for possibly shorter EFs. The latter becomes especially painful when considering the fact that a packet should fit the network MTU size: several short EFs cause a rapid bloat with pad bytes. So IMO the new proposal is superior to the old RFC7822. With respect to the EF length field and the least significant two bits: ----------------------------------------------------------------------- If the we ever plan to use them for anything, the proper wording would go along the line of: "The two least significant bits of the the EF length field are reserved. They MUST be ignored in the computation of the field length when dissecting a packet, and they MUST be set to zero when assembling a packet." Otherwise it would make sense to state that the two least significant EF length bits MUST be zero. (IMHO it would make more sense to permit *any* size of an EF and require the assembling/dissecting stages to do the alignment on DWORD boundaries, but doing so now would probably cause too much controversial issues.) About parsing ambiguities: -------------------------- IMHO a packet that uses EFs and legacy mac SHOULD use the LAST-EF indicator. This still leaves a mess on the dissecting side, since we have to live with the ambiguities caused by legacy instances of NTPD. It just might reduce the hit frequency. About multiple hash-EFs: ------------------------ We have two options here: 1st) Any hash EF contains all data (except non-hash EFs, of course) up to and including its key identifier. This makes the hash calculation somewhat easier. 2nd) EFs containing a hash are NOT part of other hashes. This is a bit more symmetric. Note that we have to parse the packet anyway to skip EFs that should not be hash-secured, so the algorithmic effort is nearly the same for both variants. Hashing of EF headers: ---------------------- In general: Is the EF header part of *all* EFs part of the hash? This would protect all EF headers from tampering (and therefore the chain we follow when dissecting the message!). Only the payload of non-secured EFs would be skipped in this case. Maybe I just didn't find that point, but I think we should be rather clear about this. About Crypto-NAK: ----------------- I know this will not happen, but this recipe for disaster should be done with. This *unauthenticated* packet can cause an authenticated communication to fail, and it is easy enough to inject into a network to facilitate a DoS attack. All attempts to make Crypto-NAK in its current form secure are in vain. (Oh, and there's at least one instance of 'thru' as short form of 'through'. Not sure if that's good style for an RFC... but remember I'm no native speaker ;) I just hope I didn't stir the waters too much :) Cheers, Pearly From nobody Thu Dec 14 00:00:11 2017 Return-Path: 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 67BF7127011 for ; Thu, 14 Dec 2017 00:00:09 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 479cmWiUz4tW for ; Thu, 14 Dec 2017 00:00:07 -0800 (PST) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F1F1200CF for ; Thu, 14 Dec 2017 00:00:07 -0800 (PST) Received: from hms-mbp11.pfcs.com (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id DC30EB89E; Thu, 14 Dec 2017 08:00:06 +0000 (UTC) To: "ntp@ietf.org" Cc: Juergen Perlinger From: Harlan Stenn Message-ID: Date: Thu, 14 Dec 2017 00:00:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ntp] Feedback on draft-aanchal4-ntp-mac X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 08:00:09 -0000 The document says: 3. Replacement Recommendation If authentication is implemented, then AES-CMAC as specified in RFC 4493 [RFC4493] SHOULD be computed over all fields in the NTP header, and any extension fields that are present in the NTP packet as described in RFC 5905 [RFC5905]. The MAC key for NTP SHOULD be 128 bits long AES-128 key and the resulting MAC tag SHOULD be 128 bits long as stated in section 2.4 of RFC 4493 [RFC4493]. NTP makes this transition possible as it supports algorithm agility as described in Section 2.1 of RFC 7696 [RFC7696]. The following are not defined in the document. Should they be? - MAC key - MAC tag Why was "SHOULD" used in the language above? How would things behave if any of the values above were not 128 bits long? Should: The MAC key for NTP SHOULD be 128 bits long AES-128 key ... be: The MAC key for NTP SHOULD be the 128 bit long AES-128 key ... RFC4493 requires a 128 bit key. Is it the intent of the authors that the only allowed key length will be 128 bits? Users might not be that precise, and since these keys will likely be used interactively for configuration purposes (manual configuration, mode 6 passwords, sntp authentication, etc.) there is benefit to be had by specifying how to extend a shorter key, or how to shorten a longer key. Anything other than clearly describing these processes in this document will lead to difficult user acceptance and/or interoperability problems. I submit these issues must be properly addressed before advancing this document. -- Harlan Stenn http://networktimefoundation.org - be a member! From nobody Thu Dec 14 08:45:57 2017 Return-Path: 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 6A8E11288B8 for ; Thu, 14 Dec 2017 08:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 tGduReFQrAz8 for ; Thu, 14 Dec 2017 08:45:54 -0800 (PST) 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 E34191273B1 for ; Thu, 14 Dec 2017 08:45:54 -0800 (PST) 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 D3196880EA for ; Thu, 14 Dec 2017 08:45:54 -0800 (PST) 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 930DE3280AE4 for ; Thu, 14 Dec 2017 08:45:54 -0800 (PST) To: ntp@ietf.org References: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de> <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> From: Brian Haberman Message-ID: Date: Thu, 14 Dec 2017 11:45:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 16:45:56 -0000 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 schrieb am 22.09.2017 um 08:26 in Nachricht >> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>: >> >>> On 9/21/17 11:02 PM, Ulrich Windl wrote: >>>>>>> Harlan Stenn schrieb am 21.09.2017 um 00:42 in Nachricht >>>> : >>>> >>>>> >>>>> On 9/20/17 12:10 PM, Brian Haberman wrote: >>>>>> >>>>>> >>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote: >>>>>>>>>> Brian Haberman schrieb am 18.09.2017 um 19:10 in >>>>>>> Nachricht : >>>>>>>> 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 From nobody Thu Dec 14 11:00:49 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F344C127136; Thu, 14 Dec 2017 11:00:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151327804295.13994.8703659243013410827@ietfa.amsl.com> Date: Thu, 14 Dec 2017 11:00:42 -0800 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-bcp-06.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 19:00:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Network Time Protocol Best Current Practices Authors : Denis Reilly Harlan Stenn Dieter Sibold Filename : draft-ietf-ntp-bcp-06.txt Pages : 22 Date : 2017-12-14 Abstract: NTP Version 4 (NTPv4) has been widely used since its publication as RFC 5905 [RFC5905]. This documentation is a collection of Best Practices from across the NTP community. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-bcp-06 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-bcp-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 14 13:48:35 2017 Return-Path: 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 F21BC128D44 for ; Thu, 14 Dec 2017 13:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 kgIJ4W9Won2x for ; Thu, 14 Dec 2017 13:48:32 -0800 (PST) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673741243F3 for ; Thu, 14 Dec 2017 13:48:32 -0800 (PST) Received: from [10.66.254.3] (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id D8E84B86C; Thu, 14 Dec 2017 21:48:31 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Harlan Stenn X-Mailer: iPhone Mail (15B202) In-Reply-To: Date: Thu, 14 Dec 2017 13:48:27 -0800 Cc: ntp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F1C07D9-E46B-413D-9B4F-75D27D53EA6F@nwtime.org> References: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de> <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> To: Brian Haberman Archived-At: Subject: Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 21:48:34 -0000 Partial answer: we know the gross version the client wants because it=E2=80=99= s in the base packet.=20 We=E2=80=99re about to have some interesting discussions. And I bet they=E2=80=99ll be very similar to the ones we should be having ab= out the Yang Data model, and a reexamination of the NTP SNMP spec.=20 Sent from my iPhone. Please excuse brevity and typos. > On Dec 14, 2017, at 8:45 AM, Brian Haberman wro= te: >=20 > Reviving this thread because we never reached any consensus on what > things we want in the mode-6-cmds draft... >=20 >> On 9/22/17 3:47 AM, Harlan Stenn wrote: >>=20 >>=20 >> On 9/22/2017 12:05 AM, Ulrich Windl wrote: >>>>>> Harlan Stenn schrieb am 22.09.2017 um 08:26 in Nac= hricht >>> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>: >>>=20 >>>> On 9/21/17 11:02 PM, Ulrich Windl wrote: >>>>>>>> Harlan Stenn schrieb am 21.09.2017 um 00:42 in N= achricht >>>>> : >>>>>=20 >>>>>>=20 >>>>>>> On 9/20/17 12:10 PM, Brian Haberman wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote: >>>>>>>>>>> Brian Haberman schrieb am 18.09.2017 u= m 19:10 in >>>>>>>> Nachricht = : >>>>>>>>> Ulrich noted that this document does not specify a version number f= or >>>>>>>>> the mode 6 commands. I had suggested specifying it as "version 4 (= or >>>>>>>>> earlier)" given that the introduction of mode 6 commands has occur= red at >>>>>>>>> various versions of the protocol starting at RFC 1305. Ulrich poin= ted >>>>>>>>> out that the version number drives the interpretation of the statu= s words. >>>>>>>>>=20 >>>>>>>>> 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? >>>>>>>>=20 >>>>>>>> Hi! >>>>>>>>=20 >>>>>>>> I think there are several issues: >>>>>>>>=20 >>>>>>>> 1) Assuming there are different versions (there are!), how can one f= ind out=20 >>>>>> which version the server implements? See 2) >>>>>>>>=20 >>>>>>>> 2) if a client requests a version different from the server, what s= hould the=20 >>>>=20 >>>>>> server do? The server could respond with a different version number,=20= >>>>>> indicating that it is not willing to respond / privide the informatio= n in=20 >>>> the=20 >>>>>> format requested. Or the server could respond with a "bad request" st= atus.=20 >>>>>> Finally the server could respond in the format requested... I have sl= ight=20 >>>>>> favor for the first variant unless there is a command to find out wha= t=20 >>>>>> message format versions the server can provide. >>>>>>>>=20 >>>>>>>> 3) As it seems to be now, the server ignores the version (versions 2= , 3, and=20 >>>>=20 >>>>>> 4 all seem to work) >>>>>>>>=20 >>>>>>>=20 >>>>>>> The above seems to argue for two things: >>>>>>>=20 >>>>>>> 1) A preliminary handshake between an NTP server and the mode6-speak= ing >>>>>>> client to determine what version is in use. >>>>>>>=20 >>>>>>> 2) A change to the operating basis of the mode 6 commands in that th= e >>>>>>> above mentioned handshake occurs before actually sending the mode 6 c= ommand. >>>>>>>=20 >>>>>>> Is that a good representation of what is being asked for? >>>>>>=20 >>>>>> If it is, I'm thinking we'd want a mode 6 "Identify" command, that wo= uld >>>>>> have this information in a response. This response would likely cont= ain >>>>>> different data before/after authentication. >>>>>=20 >>>>> Why that? You should elaborate on the role of authentication. >>>>=20 >>>> Here's a short list. >>>>=20 >>>> - Nobody but trusted folks should see the origin timestamp of a pending= >>>> symmetric mode exchange. >>>>=20 >>>> - Nobody but trusted folks should be able to get the list of our >>>> potential servers. >>>>=20 >>>> - Nobody but VERY trusted folks should be able to issue :config >>>> directives >>>=20 >>> Hi Harlan, >>>=20 >>> 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 protoc= ol level, but these issues should be clearly separated IMHO. >>=20 >> 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. >=20 > I can interpret this capability in two ways: >=20 > 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 versio= n. >=20 > 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. >=20 > 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. >=20 > Other thoughts? >=20 > Regards, > Brian >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp >=20 From nobody Mon Dec 18 00:20:24 2017 Return-Path: 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 B4C7F12421A for ; Mon, 18 Dec 2017 00:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 HOY2ldAEogpz for ; Mon, 18 Dec 2017 00:20:19 -0800 (PST) Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B76F1200F3 for ; Mon, 18 Dec 2017 00:20:19 -0800 (PST) Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5B6865D2BA for ; Mon, 18 Dec 2017 09:20:17 +0100 (CET) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id 7909A5CFB6 for ; Mon, 18 Dec 2017 09:20:15 +0100 (CET) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Mon, 18 Dec 2017 09:20:15 +0100 Message-Id: <5A377A3D020000A1000295D1@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 18.0.0 Date: Mon, 18 Dec 2017 09:20:13 +0100 From: "Ulrich Windl" To: "ntp@ietf.org" , References: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de> <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 08:20:23 -0000 >>> Brian Haberman schrieb am 14.12.2017 um = 17:45 in Nachricht : > Reviving this thread because we never reached any consensus on what > things we want in the mode-6-cmds draft... >=20 > On 9/22/17 3:47 AM, Harlan Stenn wrote: >>=20 >>=20 >> On 9/22/2017 12:05 AM, Ulrich Windl wrote: >>>>>> Harlan Stenn schrieb am 22.09.2017 um 08:26 in = Nachricht >>> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>: >>> >>>> On 9/21/17 11:02 PM, Ulrich Windl wrote: >>>>>>>> Harlan Stenn schrieb am 21.09.2017 um 00:42 in = Nachricht >>>>> : >>>>> >>>>>> >>>>>> On 9/20/17 12:10 PM, Brian Haberman wrote: >>>>>>> >>>>>>> >>>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote: >>>>>>>>>>> Brian Haberman schrieb am 18.09.2017= um 19:10 in >>>>>>>> Nachricht : >>>>>>>>> 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=20 >>>>>> which version the server implements? See 2) >>>>>>>> >>>>>>>> 2) if a client requests a version different from the server, what = should the=20 >=20 >>>> >>>>>> server do? The server could respond with a different version = number,=20 >>>>>> indicating that it is not willing to respond / privide the = information in=20 >>>> the=20 >>>>>> format requested. Or the server could respond with a "bad request" = status.=20 >>>>>> Finally the server could respond in the format requested... I have = slight=20 >>>>>> favor for the first variant unless there is a command to find out = what=20 >>>>>> message format versions the server can provide. >>>>>>>> >>>>>>>> 3) As it seems to be now, the server ignores the version = (versions 2, 3, and=20 >=20 >>>> >>>>>> 4 all seem to work) >>>>>>>> >>>>>>> >>>>>>> The above seems to argue for two things: >>>>>>> >>>>>>> 1) A preliminary handshake between an NTP server and the mode6-spea= king >>>>>>> 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=20 > 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=20 > level, but these issues should be clearly separated IMHO. >>=20 >> 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. >=20 > I can interpret this capability in two ways: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Other thoughts? Hi! Variant 1 would require a different interpretation of existing commands = (i.e.: consider the incoming version number), while variant 2 just adds = one additional command, leaving others alone. Maybe consider how a more modern protocol like IPP (see RFC 8011, section = 4.1.8) handles that (in a nutshell): The client sends an expected version number: If the server supports it, = everything is fine; if not the server also tells the client what the = supported version numbers are. In addition every answer from the server = consideres the version number requested by the client. I think the most important issue about all that is that any change to the = result message (like new or removed variable names) MUST change the = version number. The other question is whether this version number is the NTP protocol = version number (VN), or some new variable like "mode-6-protocol-version" = (or anything shorter). Regards, Ulrich >=20 > Regards, > Brian >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org=20 > https://www.ietf.org/mailman/listinfo/ntp From nobody Mon Dec 18 00:26:06 2017 Return-Path: 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 DFB191270AE for ; Mon, 18 Dec 2017 00:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 mr4eSxrJVZYN for ; Mon, 18 Dec 2017 00:26:03 -0800 (PST) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A403D126CC4 for ; Mon, 18 Dec 2017 00:26:03 -0800 (PST) Received: from hms-mbp11.pfcs.com (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id BB2D2B837; Mon, 18 Dec 2017 08:26:02 +0000 (UTC) To: ntp@ietf.org References: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de> <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> <5A377A3D020000A1000295D1@gwsmtp1.uni-regensburg.de> From: Harlan Stenn Message-ID: <4f1a0e7a-0cf7-dc54-1039-80cc6223fcbc@nwtime.org> Date: Mon, 18 Dec 2017 00:26:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5A377A3D020000A1000295D1@gwsmtp1.uni-regensburg.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 08:26:06 -0000 I'm pretty sure we're going to need a "mode 6" version, and we're also going to need to decide about "standard" contents and "vendor-specific" contents. We're going to need this for the Yang stuff, too. H On 12/18/17 12:20 AM, Ulrich Windl wrote: > > >>>> Brian Haberman schrieb am 14.12.2017 um 17:45 in > Nachricht : >> 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 schrieb am 22.09.2017 um 08:26 in Nachricht >>>> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>: >>>> >>>>> On 9/21/17 11:02 PM, Ulrich Windl wrote: >>>>>>>>> Harlan Stenn schrieb am 21.09.2017 um 00:42 in Nachricht >>>>>> : >>>>>> >>>>>>> >>>>>>> On 9/20/17 12:10 PM, Brian Haberman wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote: >>>>>>>>>>>> Brian Haberman schrieb am 18.09.2017 um 19:10 in >>>>>>>>> Nachricht : >>>>>>>>>> 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? > > Hi! > > Variant 1 would require a different interpretation of existing commands (i.e.: consider the incoming version number), while variant 2 just adds one additional command, leaving others alone. > > Maybe consider how a more modern protocol like IPP (see RFC 8011, section 4.1.8) handles that (in a nutshell): > The client sends an expected version number: If the server supports it, everything is fine; if not the server also tells the client what the supported version numbers are. In addition every answer from the server consideres the version number requested by the client. > > I think the most important issue about all that is that any change to the result message (like new or removed variable names) MUST change the version number. > > The other question is whether this version number is the NTP protocol version number (VN), or some new variable like "mode-6-protocol-version" (or anything shorter). > > Regards, > Ulrich > >> >> Regards, >> Brian >> >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> https://www.ietf.org/mailman/listinfo/ntp > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > -- Harlan Stenn http://networktimefoundation.org - be a member! From nobody Mon Dec 18 05:11:35 2017 Return-Path: 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 63E8412785F for ; Mon, 18 Dec 2017 05:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 ZGamKXoYkbT3 for ; Mon, 18 Dec 2017 05:11:32 -0800 (PST) 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 E35F71242F7 for ; Mon, 18 Dec 2017 05:11:32 -0800 (PST) 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 BC6FA88162 for ; Mon, 18 Dec 2017 05:11:32 -0800 (PST) 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 7893E3280AE4 for ; Mon, 18 Dec 2017 05:11:32 -0800 (PST) To: "ntp@ietf.org" References: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de> <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> <5A377A3D020000A1000295D1@gwsmtp1.uni-regensburg.de> From: Brian Haberman Message-ID: <85052104-ed5c-398d-59b9-1b609e76c559@innovationslab.net> Date: Mon, 18 Dec 2017 08:11:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5A377A3D020000A1000295D1@gwsmtp1.uni-regensburg.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:11:34 -0000 On 12/18/17 3:20 AM, Ulrich Windl wrote: > > >>>> Brian Haberman schrieb am 14.12.2017 um 17:45 in > Nachricht : >> 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 schrieb am 22.09.2017 um 08:26 in Nachricht >>>> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>: >>>> >>>>> On 9/21/17 11:02 PM, Ulrich Windl wrote: >>>>>>>>> Harlan Stenn schrieb am 21.09.2017 um 00:42 in Nachricht >>>>>> : >>>>>> >>>>>>> >>>>>>> On 9/20/17 12:10 PM, Brian Haberman wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote: >>>>>>>>>>>> Brian Haberman schrieb am 18.09.2017 um 19:10 in >>>>>>>>> Nachricht : >>>>>>>>>> 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? > > Hi! > > Variant 1 would require a different interpretation of existing commands (i.e.: consider the incoming version number), while variant 2 just adds one additional command, leaving others alone. I asked the above questions the way I did based on my interpretation of what this draft is trying to accomplish. There have been numerous complaints that the mode 6 commands were lost when RFC 1305 was made obsolete when 5905 was published without carrying the mode 6 commands forward. This document is supposed to be the informational reference for the existing mode 6 commands. >From the abstract of the draft: The goal of this document is to provide a historic description of the control messages. I certainly don't see WG consensus to change the focus of this document from a historical documentation exercise to a re-definition of mode 6... > > Maybe consider how a more modern protocol like IPP (see RFC 8011, section 4.1.8) handles that (in a nutshell): > The client sends an expected version number: If the server supports it, everything is fine; if not the server also tells the client what the supported version numbers are. In addition every answer from the server consideres the version number requested by the client. > > I think the most important issue about all that is that any change to the result message (like new or removed variable names) MUST change the version number. > > The other question is whether this version number is the NTP protocol version number (VN), or some new variable like "mode-6-protocol-version" (or anything shorter). >From Section 2 of the draft: Version Number (VN): This is a three-bit integer indicating a minimum NTP version number. Regards, Brian From nobody Mon Dec 18 23:44:18 2017 Return-Path: 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 29A2012DA07 for ; Mon, 18 Dec 2017 23:44:17 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 LXMdQTaJ3Z8r for ; Mon, 18 Dec 2017 23:44:13 -0800 (PST) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA3C12DA3D for ; Mon, 18 Dec 2017 23:44:10 -0800 (PST) Received: from hms-mbp11.pfcs.com (96-41-166-181.dhcp.mdfd.or.charter.com [96.41.166.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 6BF9FB837; Tue, 19 Dec 2017 07:44:09 +0000 (UTC) To: ntp@ietf.org References: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de> <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> <5A377A3D020000A1000295D1@gwsmtp1.uni-regensburg.de> <85052104-ed5c-398d-59b9-1b609e76c559@innovationslab.net> From: Harlan Stenn Message-ID: Date: Mon, 18 Dec 2017 23:44:07 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <85052104-ed5c-398d-59b9-1b609e76c559@innovationslab.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1 X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 07:44:17 -0000 On 12/18/17 5:11 AM, Brian Haberman wrote: > > > On 12/18/17 3:20 AM, Ulrich Windl wrote: >> >> >>>>> Brian Haberman schrieb am 14.12.2017 um 17:45 in >> Nachricht : >>> 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 schrieb am 22.09.2017 um 08:26 in Nachricht >>>>> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>: >>>>> >>>>>> On 9/21/17 11:02 PM, Ulrich Windl wrote: >>>>>>>>>> Harlan Stenn schrieb am 21.09.2017 um 00:42 in Nachricht >>>>>>> : >>>>>>> >>>>>>>> >>>>>>>> On 9/20/17 12:10 PM, Brian Haberman wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote: >>>>>>>>>>>>> Brian Haberman schrieb am 18.09.2017 um 19:10 in >>>>>>>>>> Nachricht : >>>>>>>>>>> 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? >> >> Hi! >> >> Variant 1 would require a different interpretation of existing commands (i.e.: consider the incoming version number), while variant 2 just adds one additional command, leaving others alone. > > I asked the above questions the way I did based on my interpretation of > what this draft is trying to accomplish. There have been numerous > complaints that the mode 6 commands were lost when RFC 1305 was made > obsolete when 5905 was published without carrying the mode 6 commands > forward. This document is supposed to be the informational reference for > the existing mode 6 commands. OK. I asked that mode 6 be added back in because it's something that's been in active use to monitor and manage NTP instances for over 20 years' time. >>From the abstract of the draft: > > The goal of this document is to provide a historic description of the > control messages. > > > I certainly don't see WG consensus to change the focus of this document > from a historical documentation exercise to a re-definition of mode 6... Since the reference implementation has been doing mode 6 for a very long time, there's little value to me in documenting historical behavior in an RFC. I do think there is value in an RFC that describes current practice, that is also used for any current changes. This is the base information that a conforming implementation would use to implement RFC5907 (the SNMP mapping) and the Yang data model stuff. I'll even go one better and suggest that we should have a list of common pieces of information that SHOULD/MUST be implemented, perhaps a list of items that MAY be implemented, and a means to map these to mode 6, SNMP and Yang. There also needs to be a way to deal with implementation-specific data. Without this level of detail, there won't be a useful or easy way to have a monitoring/management tool talk with an NTP instance in anything other than an implementation-specific way. >> >> Maybe consider how a more modern protocol like IPP (see RFC 8011, section 4.1.8) handles that (in a nutshell): >> The client sends an expected version number: If the server supports it, everything is fine; if not the server also tells the client what the supported version numbers are. In addition every answer from the server consideres the version number requested by the client. >> >> I think the most important issue about all that is that any change to the result message (like new or removed variable names) MUST change the version number. >> >> The other question is whether this version number is the NTP protocol version number (VN), or some new variable like "mode-6-protocol-version" (or anything shorter). > >>From Section 2 of the draft: > > Version Number (VN): This is a three-bit integer indicating a minimum > NTP version number. That's the NTP Protocol version, and isn't particularly useful for this. We've already seen the v4 ntpq change from reporting dispersion to reporting jitter. We've seen changes in some other values, too. It seems to me the value in this work is so folks can write tools to monitor and manage their NTP instances, and that gets lots easier if the API and values are documented. -- Harlan Stenn http://networktimefoundation.org - be a member!