Re: [Ntp] NTPv5 draft suggestion to move timescale offset into extension fields.

Miroslav Lichvar <mlichvar@redhat.com> Mon, 07 November 2022 14:58 UTC

Return-Path: <mlichvar@redhat.com>
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 B7DAFC1524B5 for <ntp@ietfa.amsl.com>; Mon, 7 Nov 2022 06:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.679
X-Spam-Level:
X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD3_c2K6IYjS for <ntp@ietfa.amsl.com>; Mon, 7 Nov 2022 06:58:51 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC298C14F75F for <ntp@ietf.org>; Mon, 7 Nov 2022 06:58:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667833129; 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=6CoH+4qT5aeZxQ2vHLEXtxm8Kj+S0sKazFsKRXsBBpI=; b=cKwz/nKuXJcUXwuOXTHlbJmeNdwtD674fWQWjDXEvFnSH82V6YDtzvhA3EqyD5kgBcwclJ /1tm9so3zzJ737i4SUNkDfbe/rEugJF4ko6nayblHjBA1MuS7eVsvbKklaZ2bU/6i+WJ1C u0gKxyGRECIQVAxPc3ECRbGjKgFEe6g=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-104-MHQ1_VZdM9mc2VOLu2bjvw-1; Mon, 07 Nov 2022 09:58:43 -0500
X-MC-Unique: MHQ1_VZdM9mc2VOLu2bjvw-1
Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A60A988B767; Mon, 7 Nov 2022 14:58:43 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3138F477F5E; Mon, 7 Nov 2022 14:58:42 +0000 (UTC)
Date: Mon, 07 Nov 2022 15:58:41 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: David Venhoek <david@venhoek.nl>
Cc: ntp@ietf.org
Message-ID: <Y2kdIeEXSfB6DcyM@localhost>
References: <CAPz_-SU7rctchBVvm59YAoEA7p8Or9aqdGovJ2E98Tp85jVsWQ@mail.gmail.com> <Y2jCtzeJZfz2daYJ@localhost> <CAPz_-SVkFZaycpimBGy-pZRgwxo9pdnrmh7QDd-=+qvXfdFKRw@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAPz_-SVkFZaycpimBGy-pZRgwxo9pdnrmh7QDd-=+qvXfdFKRw@mail.gmail.com>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/k5U_VjANtw6wlsS7x-d5ccxVgYc>
Subject: Re: [Ntp] NTPv5 draft suggestion to move timescale offset into extension fields.
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 07 Nov 2022 14:58:51 -0000

On Mon, Nov 07, 2022 at 02:28:58PM +0000, David Venhoek wrote:
> As for not using a new timetype, that could work, however, then we
> need to include an era number to ensure that the indicated timestamp
> is unambiguous.

It would be the era in which the offset is smaller, same as with the
transmit timestamp, which doesn't have an associated era number.

Do you expect larger timescale offsets? In that case the 64-bit signed
offset would not be sufficient either.

-- 
Miroslav Lichvar