[Ntp] Antw: Re: Antw: Re: Antw: [EXT] Éric Vyncke's No Objection on draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Mon, 24 August 2020 11:59 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 190553A0D07; Mon, 24 Aug 2020 04:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IIZAyH4NZl21; Mon, 24 Aug 2020 04:59:38 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28003A0CFC; Mon, 24 Aug 2020 04:59:37 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id 439026000053; Mon, 24 Aug 2020 13:59:34 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx2.uni-regensburg.de (Postfix) with ESMTP id 15CF8600004E; Mon, 24 Aug 2020 13:59:34 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 24 Aug 2020 13:59:34 +0200
Message-Id: <5F43ABA4020000A10003AC7B@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.1
Date: Mon, 24 Aug 2020 13:59:32 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <evyncke@cisco.com>,"The IESG" <iesg@ietf.org>, <stenn@nwtime.org>
Cc: <draft-ietf-ntp-mode-6-cmds@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>,<odonoghue@isoc.org>
References: <159802037308.10371.11780852739141456472@ietfa.amsl.com> <5F43559A020000A10003AC33@gwsmtp.uni-regensburg.de> <d3ea413d-c2f6-3168-cfba-54f5a27a2b22@nwtime.org> <5F4397C7020000A10003AC6B@gwsmtp.uni-regensburg.de> <ce2502e7-affa-5c38-6d18-69489f759e91@nwtime.org>
In-Reply-To: <ce2502e7-affa-5c38-6d18-69489f759e91@nwtime.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/c2EVN5AOMcCpAhZBYNrw56LcLvo>
Subject: [Ntp] =?utf-8?b?QW50dzogUmU6ICBBbnR3OiBSZTogQW50dzogW0VYVF0gw4ly?= =?utf-8?q?ic_Vyncke=27s_No_Objection_on_draft-ietf-ntp-mode-6-cmds-09=3A_?= =?utf-8?q?=28with_COMMENT=29?=
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Aug 2020 11:59:40 -0000

>>> Harlan Stenn <stenn@nwtime.org> schrieb am 24.08.2020 um 13:41 in

> On 8/24/2020 3:34 AM, Ulrich Windl wrote:
>>>>> Harlan Stenn <stenn@nwtime.org> schrieb am 24.08.2020 um 10:52 in
>> Nachricht
>> <d3ea413d-c2f6-3168-cfba-54f5a27a2b22@nwtime.org>rg>:
>>> On 8/23/2020 10:52 PM, Ulrich Windl wrote:
>>>>>>> Éric Vyncke via Datatracker <noreply@ietf.org> schrieb am 21.08.2020
>>>> 16:32
>>>> in Nachricht <159802037308.10371.11780852739141456472@ietfa.amsl.com>om>:
>>>> ...
>>>>> -- Appendix A --
>>>>> Is there a reason why the mode 7 is in the appendix and not in the main
>> body
>>>>> ?
>>>> Because it's a different (and really obsolete) protocol. At least per
>>>> specification, maybe not by implementation.
>>> No, it is not obsolete.  Mode 7 is for vendor-specific operations.
>> You mean mode 7 has been "reassigned"? Otherwise you contradict to what
>> were postulating many times before.
>> It seems I don't quite understand: If leaving mode-7 to solely
>> vendor-implementation, there will be a true protocol mess.
>> At least some framework to implement vendor-specific operations is needed
>> IMHO.
>> So a server would hopefully recognize at least that it does not understand

> the
>> command being received and return an error message that the client can
>> decode...
> Sorry, Ulrich - I don't know what you're talking about.


it's about "Mode 7 is for vendor-specific operations.". I read it that
different implementation may use mode-7 to implement arbitrary protocols with
that, while currently there's (AFAIK) exactly one "vendor" that had an
implementation. So not to make matters worse, I'd make this obsolete now,
allowing to redefince that in a useful way later for NTP version 6 or so.


> Mode 6 has always been "control mode", and has been expected to have
> standard/common assignments.  I believe the document could/should cover
> more than it does, just like I expect a lot more from the NTP Yang Data
> Model document.  I continue to believe that there needs to be a
> standardized way to exchange minimally-expected "control mode" data with
> an NTP server via mode 6, and there needs to be a good way for
> implementations to augment the minimal set of mode 6 subcommands.
> Mode 7 has always been "private mode", and is expected to be
> vendor/implementation specific.
> This is all described in RFC-1305, Appendix D, section 2.
> The document we're talking about here is the WG's attempt to fix at
> least the oversight of 5905 not talking about mode 6.
> Folks should be able to infer the NTP Project's position of this
> document by my vote on the document.
> With regard to mode 7, I'm not aware of any attempts by the WG to
> document anything beyond what RFC5905 contains in 7.3 Packet Header
> Variables beyond that in Figure 10, Association Modes, and given that
> mode 7 is "reserved for private use", I'm not sure what anybody might
> want for that.  Mode 7 has and continues to be a control message for
> vendor/implementation specific use.
>>> It is there to carve a space for implementation/vendor-specific stuff.
>>> -- 
>>> Harlan Stenn <stenn@nwtime.org>
>>> http://networktimefoundation.org - be a member!
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp 
> -- 
> Harlan Stenn <stenn@nwtime.org>
> http://networktimefoundation.org - be a member!