IETF Logo Mail Archive

[Ntp] 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 10:34 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBC13A0C50; Mon, 24 Aug 2020 03:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqNq8jKHnLGv; Mon, 24 Aug 2020 03:34:53 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [194.94.157.149]) (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 C78373A0C4E; Mon, 24 Aug 2020 03:34:52 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 455D86000069; Mon, 24 Aug 2020 12:34:50 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id 30B1A600004A; Mon, 24 Aug 2020 12:34:50 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 24 Aug 2020 12:34:49 +0200
Message-Id: <5F4397C7020000A10003AC6B@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.1
Date: Mon, 24 Aug 2020 12:34:47 +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>
In-Reply-To: <d3ea413d-c2f6-3168-cfba-54f5a27a2b22@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/2lW8jPNknSqdlwZ5nB7EHf_Ze8Y>
Subject: [Ntp] Antw: Re: Antw: [EXT] Éric Vyncke's No Objection on draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)
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 10:34:56 -0000

>>> Harlan Stenn <stenn@nwtime.org> schrieb am 24.08.2020 um 10:52 in
Nachricht
<d3ea413d-c2f6-3168-cfba-54f5a27a2b22@nwtime.org>:
> On 8/23/2020 10:52 PM, Ulrich Windl wrote:
>>>>> Éric Vyncke via Datatracker <noreply@ietf.org> schrieb am 21.08.2020 um
>> 16:32
>> in Nachricht <159802037308.10371.11780852739141456472@ietfa.amsl.com>:
>>...
>>>
>>> -- 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 you
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...

> 
> It is there to carve a space for implementation/vendor-specific stuff.
> 
> -- 
> Harlan Stenn <stenn@nwtime.org>
> http://networktimefoundation.org - be a member!

v2.23.0 | Report a Bug | By Email