IETF Logo Mail Archive

Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

Martin Burnicki <martin.burnicki@meinberg.de> Fri, 22 October 2021 12:19 UTC

Return-Path: <martin.burnicki@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 261123A0BCA for <ntp@ietfa.amsl.com>; Fri, 22 Oct 2021 05:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 OWy_GCHVgP50 for <ntp@ietfa.amsl.com>; Fri, 22 Oct 2021 05:19:02 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796103A0BC8 for <ntp@ietf.org>; Fri, 22 Oct 2021 05:19:01 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 4044371C1394; Fri, 22 Oct 2021 14:18:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=d2021; t=1634905139; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bhzqOtvLf012UJrcr6WpBPu3TWoaMj+hQxLqbvElEC0=; b=gxOHcWBUbbkWLsvyiyUXTH1x8eoORvDtDssr2FFOwhk7Ugfpw2JzKb3NwZIjfsMxsPvW6k lnakPYLvGoe5aOCNs+vtWXdnrPFxvhFXawTYGNIESVYYKlDFT9vgVf9Fmc4PrSUAfCfrUR 5knRgq6ErdGmSaT1q8mrcr8xzh50TgW01D1fPnoEQWXu0UswBMrVGrYfnkEYGVObQCIqz8 jBJRKmdJlCmASrkS56k3ClYJcDzsN6J8lhT77YCtOOQOPdT1wQqmU6xUv9HwTghl8YuF6S TYuPjM0pcjOkPneOg1vF7ZCGwtLlesH0TSxJ5u9/8K5DqhUEBhqcee0WD15Cjw==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Fri, 22 Oct 2021 14:18:58 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)); Fri, 22 Oct 2021 14:18:57 +0200
Message-ID: <b7c9724d-b5e9-6318-211f-45b39d2dcd99@meinberg.de>
Date: Fri, 22 Oct 2021 14:18:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0
Content-Language: en-US
To: Danny Mayer <mayer@pdmconsulting.net>, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, doug.arnold@meinberg-usa.com, mlichvar@redhat.com, halmurray+ietf@sonic.net
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <D19C98F0020000AAAB822621@gwsmtp.uni-regensburg.de> <B6193D9D02000051AB59E961@gwsmtp.uni-regensburg.de> <84735FB40200007C44DF974D@gwsmtp.uni-regensburg.de> <236983740200003E824A10E1@gwsmtp.uni-regensburg.de> <CEFD0B92020000436A6A8CFC@gwsmtp.uni-regensburg.de> <616E7B69020000A10004491E@gwsmtp.uni-regensburg.de> <DB577C29020000EF6A6A8CFC@gwsmtp.uni-regensburg.de> <616E933D020000A100044957@gwsmtp.uni-regensburg.de> <72083C72020000E06A6A8CFC@gwsmtp.uni-regensburg.de> <D11527C602000032FDA5B133@gwsmtp.uni-regensburg.de> <9E2EA18B020000B86A6A8CFC@gwsmtp.uni-regensburg.de> <6EFADD85020000BDFDA5B133@gwsmtp.uni-regensburg.de> <61714B21020000A100044B83@gwsmtp.uni-regensburg.de> <AM7PR02MB576513760641C35EB5B43673CFBF9@AM7PR02MB5765.eurprd02.prod.outlook.com> <61727020020000A100044BE7@gwsmtp.uni-regensburg.de> <c1e5ade3-2693-c684-66de-0c306036dc1e@meinberg.de> <cc5fb67c-a2a8-1f18-37a7-c79a80326ed2@pdmconsulting.net>
From: Martin Burnicki <martin.burnicki@meinberg.de>
Organization: Meinberg Funkuhren GmbH & Co. KG, Bad Pyrmont, Germany
In-Reply-To: <cc5fb67c-a2a8-1f18-37a7-c79a80326ed2@pdmconsulting.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------NSaIlicc4PAFFRmlepDALyZK"
X-SM-outgoing: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/JXAPwn979us_0LSbcKWsQ7Azojo>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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: Fri, 22 Oct 2021 12:19:12 -0000

Danny Mayer wrote:
> On 10/22/21 6:00 AM, Martin Burnicki wrote:
>> As I've tried to point out earlier, in any case it's the task of an 
>> administrator to ensure a proper configuration:
>>
>> - If there are smearing and not-smearing servers, he has to configure 
>> which clients should query the time from which servers.
>>
>> - If the clients should do the smearing, he had to configure each 
>> individual client whether to smear, or not.
>>
>> - If a smearing server would only reply to authenticated requests, he 
>> had to configure on each client which server(s) to use, and which 
>> keys, and it wouldn't even be possible to hide the leap second from 
>> dumb clients.
>>
> You also need to worry about the cascading effects of a server accepting 
> smeared time turning around a sending out smeared timestamps in response 
> to requests from downstream clients. Smearing cannot be considered in 
> isolation.

Correct. Cascading servers, mixing smearing and non-smearing time 
sources, providing smearing clients with a leap second file, etc. are 
another stage of potential problems an admin has to keep in mind in all 
of the cases I mentioned.

As I said, smearing is a hack, and I just wanted to point out that it's 
not easier to let the clients do the smearing, as some folks here seem 
to assume.

In fact, one of the original reasons why Google introduces server-side 
smearing was that the only had to configure this on a few servers, and 
the configuration of a huge number of clients that were anyway sync'ing 
to those servers didn't need to be touched.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

v2.23.0 | Report a Bug | By Email