[Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Thu, 29 August 2019 06:21 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 4FF281201EF for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 23:21:43 -0700 (PDT)
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, SPF_HELO_NONE=0.001, 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 pbK7A99OnFx8 for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 23:21:41 -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 108661201E5 for <ntp@ietf.org>; Wed, 28 Aug 2019 23:21:40 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4C4596000052 for <ntp@ietf.org>; Thu, 29 Aug 2019 08:21:38 +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 319D6600004E for <ntp@ietf.org>; Thu, 29 Aug 2019 08:21:37 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 29 Aug 2019 08:21:37 +0200
Message-Id: <5D676EF0020000A1000332D3@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Thu, 29 Aug 2019 08:21:36 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "ntp@ietf.org" <ntp@ietf.org>,<mlichvar@redhat.com>
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de> <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de> <20190828103752.GI24761@localhost> <4795977E-23DA-4BC1-838B-C687F18EBB8B@meinberg.de> <20190828125211.GN24761@localhost>
In-Reply-To: <20190828125211.GN24761@localhost>
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/jpMchzj_r5Bkxb0qLn-anN99OVU>
Subject: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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: Thu, 29 Aug 2019 06:21:43 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 28.08.2019 um 14:52 in
Nachricht <20190828125211.GN24761@localhost>:
> On Wed, Aug 28, 2019 at 01:08:46PM +0200, Heiko Gerstung wrote:
>> Any implementation that wants to be v4/v5 compatible can easily deal with 
> two different packet header formats IMHO. Handling this in the right way
will 
> not remotely add as much complexity as all the other v5 changes will cause.

> Think about the added complexity when someone has to implement the RefID 
> handling as described in that draft, compared to just having an additional 
> field in the packet that indicates there is a leap second smear going on, or

> there is a specific ID that you want clients to use when they refer to your

> server in their RefID field. 
> 
> Only servers care about refids.

But from the view of their time suppliers those are clients.

> 
> Consider how much code will need to be written or changed to add an
> NTPv5 support to existing implementations.
> 
> Most clients are extremely simple. They send a request with almost all
> fields set to zero and ignore most fields in the response. Ideally, I
> think upgrading such a client to NTPv5 would consist of just changing
> the version in the request and accepting the version in the response
> No other changes required. A single codepath works with NTPv2, NTPv3,
> NTPv4, NTPv5.
> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp