Re: [Ntp] Leap smearing

Hal Murray <hmurray@megapathdsl.net> Thu, 10 December 2020 20:33 UTC

Return-Path: <hmurray@megapathdsl.net>
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 3EC063A12A6 for <ntp@ietfa.amsl.com>; Thu, 10 Dec 2020 12:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wS0Ab8oRNb6N for <ntp@ietfa.amsl.com>; Thu, 10 Dec 2020 12:33:05 -0800 (PST)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id B70353A1289 for <ntp@ietf.org>; Thu, 10 Dec 2020 12:33:04 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 0EE8840605C; Thu, 10 Dec 2020 12:33:01 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Martin Burnicki <martin.burnicki=40meinberg.de@dmarc.ietf.org>
cc: ntp@ietf.org, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Martin Burnicki <martin.burnicki=40meinberg.de@dmarc.ietf.org> of "Thu, 10 Dec 2020 15:32:55 +0100." <540f9f25-5c7a-b6ac-9fcf-6eeb3162dcac@meinberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 Dec 2020 12:33:01 -0800
Message-Id: <20201210203301.0EE8840605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/VnEbh7BY3vExu0i7UGB8ZhRjD_o>
Subject: Re: [Ntp] Leap smearing
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, 10 Dec 2020 20:33:11 -0000

martin.burnicki=40meinberg.de@dmarc.ietf.org said:
> However, if you have "normal" clients and you just want to prevent your
> applications from hickups when the system time is stepped back, it's easier
> to let the server smear the time, because you only have to configure this
> once, and all clients behave the same. 

That seems appropriate when you have an existing installed base using an 
existing protocol.

But we are talking about a new protocol so there is no installed base.  It 
seems reasonable to me to move the smear decision to the client side.  But 
that forces the client to decide which means one more parameter for the admin 
to keep track of and possibly screw up.

If we decide to allow/encourage doing the smearing at the server, I think we 
should be sure to document that the reason is administrative convenience.  The 
client software should probably have a 3 way option: smeared, non-smeared, 
follow-servers.  The follow-servers option will have all the current problems 
if the selected servers don't agree.


-- 
These are my opinions.  I hate spam.