Re: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
Harlan Stenn <stenn@nwtime.org> Mon, 18 December 2017 08:26 UTC
Return-Path: <stenn@nwtime.org>
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 <ntp@ietfa.amsl.com>; 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 <ntp@ietfa.amsl.com>; 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 <ntp@ietf.org>; 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: <d5a5ba98-65f2-f2e0-a0ec-40114213fc03@innovationslab.net> <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> <fd938fee-ed5c-a0ca-148f-a20a8c72aaa5@nwtime.org> <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de> <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org> <b819ec71-5b90-7ef0-cf43-a0eb57ab0d26@innovationslab.net> <5A377A3D020000A1000295D1@gwsmtp1.uni-regensburg.de>
From: Harlan Stenn <stenn@nwtime.org>
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: <https://mailarchive.ietf.org/arch/msg/ntp/HvohTPufjmC8aw8oInVwGSPh8eU>
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: <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 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 <brian@innovationslab.net> schrieb am 14.12.2017 um 17:45 in > Nachricht <b819ec71-5b90-7ef0-cf43-a0eb57ab0d26@innovationslab.net>: >> 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 <stenn@nwtime.org> 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 <stenn@nwtime.org> schrieb am 21.09.2017 um 00:42 in Nachricht >>>>>> <fd938fee-ed5c-a0ca-148f-a20a8c72aaa5@nwtime.org>: >>>>>> >>>>>>> >>>>>>> On 9/20/17 12:10 PM, Brian Haberman wrote: >>>>>>>> >>>>>>>> >>>>>>>> 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? >>>>>>> >>>>>>> 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 <stenn@nwtime.org> http://networktimefoundation.org - be a member!
- [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 1 Brian Haberman
- Re: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 1 Harlan Stenn
- [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issue 1 Ulrich Windl
- [Ntp] Antw: Re: draft-ietf-ntp-mode-6-cmds : Issu… Ulrich Windl
- Re: [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issu… Brian Haberman
- Re: [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issu… Harlan Stenn
- Re: [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issu… Brian Haberman
- [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-cmds … Ulrich Windl
- Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-c… Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-c… Ulrich Windl
- Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-c… Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-c… Brian Haberman
- Re: [Ntp] Antw: Re: Antw: draft-ietf-ntp-mode-6-c… Harlan Stenn
- [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-ntp-mo… Ulrich Windl
- Re: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-nt… Harlan Stenn
- Re: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-nt… Brian Haberman
- Re: [Ntp] Antw: Re: Antw: Re: Antw: draft-ietf-nt… Harlan Stenn