[Ntp] Antw: Re: Antw: Re: Antw: [EXT] A different NTPv5 design

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 30 April 2020 12: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 E550B3A0811 for <ntp@ietfa.amsl.com>; Thu, 30 Apr 2020 05:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dwzKuDDLOGVt for <ntp@ietfa.amsl.com>; Thu, 30 Apr 2020 05:34:47 -0700 (PDT)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (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 E21D13A080E for <ntp@ietf.org>; Thu, 30 Apr 2020 05:34:46 -0700 (PDT)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 911C1600004E for <ntp@ietf.org>; Thu, 30 Apr 2020 14:34:43 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id 778C9600004D for <ntp@ietf.org>; Thu, 30 Apr 2020 14:34:43 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 30 Apr 2020 14:34:43 +0200
Message-Id: <5EAAC5E2020000A100038A3D@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.1
Date: Thu, 30 Apr 2020 14:34:42 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: mlichvar@redhat.com
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <7114_1588171569_5EA99331_7114_20_1_20200429144540.GD8457@localhost> <5EAA7620020000A1000389F2@gwsmtp.uni-regensburg.de> <20200430101644.GA25085@localhost> <5EAAB0D1020000A100038A21@gwsmtp.uni-regensburg.de> <20200430115622.GB25085@localhost>
In-Reply-To: <20200430115622.GB25085@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/d6iSI-WN2tY21PNSSzx9C7vaMuk>
Subject: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] A different NTPv5 design
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, 30 Apr 2020 12:34:49 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 30.04.2020 um 13:56 in
Nachricht <20200430115622.GB25085@localhost>:
> On Thu, Apr 30, 2020 at 01:04:49PM +0200, Ulrich Windl wrote:

[...]
>> > Is 14 days not enough in advance? The timestamp could be in an
>> > extension field if it needs to be provided.
>> 
>> It sounds more like the minimum. I feel like it SHOULD be 30 days at
least.
> 
> There was a time (before RFC 5905) when ntpd announced it whole month
> before. That lead to the leap indicator getting stuck as there was no
> period where it should be unset. I'd rather not risk that happening
> again.

I was talking about an extension field that ol versions don't know of AND I
was proposing to add the time when the leap event is to occur...

[...]
> 
>> Will there be versions > 7 ever?
> 
> It could be, but it would need to be saved in a different field. 7
> would mean "go look elsewhere".

My proposal was to introduce the feature right now, having the version in two
locations in parallel, and in the future only in the new location. I'm assuming
we do NOT want to redesign the packet completely...

> 
> ‑‑ 
> Miroslav Lichvar