IETF Logo Mail Archive

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

Heiko Gerstung <heiko.gerstung@meinberg.de> Wed, 28 August 2019 13:12 UTC

Return-Path: <heiko.gerstung@meinberg.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 2494A12013A for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 06:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.289
X-Spam-Level:
X-Spam-Status: No, score=-4.289 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=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 bmQenGOpYSM6 for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 06:12:10 -0700 (PDT)
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 11E54120137 for <ntp@ietf.org>; Wed, 28 Aug 2019 06:12:10 -0700 (PDT)
Received: from srv-kerioconnect.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id ADD4471C09BD; Wed, 28 Aug 2019 15:11:35 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de ADD4471C09BD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1566997928; bh=jWpucrHCRxBWeMLYW5qgEuS5QKerBwHForu+9CjccUg=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=ocu83euJo8/+wAJLv9f3GKnOwCfV4cAgEwzFEspx6MTkQapaXq+gIkW9Yje73tJEw qIyE/YMsDjYmrtL4kx/oT+WqoAe8glUDp7h7ox1m3hvQZXVvQyMY4j2m0e7tZE0r07 u6yx4GSli8K+Y0OXyPDCMC4SaGngjq2Pm9v7AtdU=
X-Kerio-Anti-Spam: Build: [Engines: 2.15.9.1266, Stamp: 3], Multi: [Enabled, t: (0.000005,0.005008)], BW: [Enabled, t: (0.000007)], RTDA: [Enabled, t: (0.262438), Hit: No, Details: v2.7.53; Id: 15.1i6tnju.1djc5klo7.ds280], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Wed, 28 Aug 2019 15:11:33 +0200
Message-ID: <C1A543B3-598A-4F7F-998E-9865D4002E9A@meinberg.de>
Thread-Topic: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MDNjYzVhNjFjMDY4OWQ0MA==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, "ntp@ietf.org" <ntp@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.3 at server1a
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/eVWtHVggdXeSB0Hz2IO9g1E_fO8>
Subject: Re: [Ntp] 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: Wed, 28 Aug 2019 13:12:13 -0000

Miroslav,

if an implementation decides that NTPv5 support is too complicated, they can stick with v4 requests. As you know, lots of those simple implementations still send v3 requests as we speak, and as long as the servers still respond to that (they do for quite some years now), there is no need for a simple implementation to implement v5 support. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 heiko.gerstung@meinberg.de 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung
 
 

On 28.08.19, 14:53 "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ietf.org im Auftrag von mlichvar@redhat.com> wrote:

    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.
    
    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

v2.23.0 | Report a Bug | By Email