Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex

Marcus Dansarie <> Tue, 21 September 2021 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83B2C3A0872 for <>; Tue, 21 Sep 2021 12:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 97N6gLxN9tiI for <>; Tue, 21 Sep 2021 12:25:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D9CA3A086E for <>; Tue, 21 Sep 2021 12:25:08 -0700 (PDT)
Received: by with SMTP id b15so1763501lfe.7 for <>; Tue, 21 Sep 2021 12:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=sender:to:references:cc:from:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=hbbmm53kAxnGK+i5yRRL01H05Yf2m7HzLtpBh+2rJwc=; b=HrRwTBWrlcfW34HIkSRJWWGK36NdSAXYVXYKW/hxOZd2Pn20kXvQYSkd1joGKP3sSe Sy9MVIVCg0hrbWn9qvpDcBiyAwJpGVdU6717J62/frAcmZhWEyIelT0e7Fv0DD8vQi1Q Uou8s/93q0zv6P+MMHTXg1gzR857yqRx4YWgarNmG0QM9gF54+vPj7AWBYdveSI4/A7Y /o0COhOJTEQS0dMzEZrvX6OYw1xHwPD/VFXwwJJUlrnsOog4syTnXiGYKY97leAePPp3 l5JAH7DVcH7Ex4lQDGkpm1aZbJYmMj7HbCDqulbvyFA3lmz4Ud7nf2lvO2E1rfUWthYX aJgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:sender:to:references:cc:from:subject:message-id :date:user-agent:mime-version:in-reply-to; bh=hbbmm53kAxnGK+i5yRRL01H05Yf2m7HzLtpBh+2rJwc=; b=TWKYqwg3IguxltMpWeENWMvGW2H/8TL4qK6wVo6heAtJMo1zpNyGnBR3618Gj2aBP3 2o1rhrzW5isE+Texyqa7+EGIk+ULNo4uPw8f6I1G1ecsda7xaW6c+BhVMhGF1MJ0t1jE tgqXU0+rQIYeEgbmgHRshjf6Q4MFqSsxgk6l5K+GSe30WsOnKOPOtIYEAetb4oPIsEAg wBEaSoMxc8CtUivYFomd2x2es6GIpy1/ST4fuJXm1lCF4k3WUok+iU7/fYCMGxoikzr6 NDXIU+EoNg3KeofEWJjSyD/b1FN9QQ04o+VTyeNy5AzKMEl9jH22/RPezcQCOTVo+Y8B vofQ==
X-Gm-Message-State: AOAM53312dA0DOdyohlff7IZPPcQRF17TMv+V4vzUBLFzz1yjNpDGJW/ OWnjh0MNYulgSYA4QB1VpSEPQryK5GY=
X-Google-Smtp-Source: ABdhPJxbxe10ozsgVGD2dFZGoxpkLaS5Ww1UqOOI+n7Ua1pFRYZTgbX7tBgDnC+9F64INnO7BBrgDw==
X-Received: by 2002:a2e:94d0:: with SMTP id r16mr30206533ljh.403.1632252304048; Tue, 21 Sep 2021 12:25:04 -0700 (PDT)
Received: from ?IPv6:2001:470:dfe6:0:d638:1db7:287:5ed5? ([2001:470:dfe6:0:d638:1db7:287:5ed5]) by with ESMTPSA id b6sm795762lfs.86.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Sep 2021 12:25:03 -0700 (PDT)
Sender: Marcus Dansarie <>
References: <> <> <> <> <>
Cc: JP Sugarbroad <>
From: Marcus Dansarie <>
Message-ID: <>
Date: Tue, 21 Sep 2021 21:24:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q4uucKacVrvRMBmuYTFmVITOl72AI70oE"
Archived-At: <>
Subject: Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Sep 2021 19:25:14 -0000

I'll hijack this thread in an attempt to answer a number of related
Roughtime questions in the same place. Apologies in advance for that.

On 2021-09-21 16:27, Danny Mayer wrote:
> It would be helpful if you explained why you changed it in the first
> place. I assume you had a good reason to do so.

I was the one to initially suggest terminating the PAD tag with zeros
instead of ones (0xff) back in 2019:

> The PAD tag key is encoded as PAD\xff, while the SIG tag key is
> encoded as SIG\x00. For consistency, this should be changed so that
> both are terminated with \x00. Additionally, terminating the tag keys
> with the NULL character will make displaying them easier on many
> platforms.

In short, terminating all "ASCII-style" tags shorter than four
characters with zeros allows for unambiguous translation into 32-bit
integer tags. The entire message is archived at:

Since a Roughtime request can currently only contain PAD, VER, and NONC
tags, where the sizes of latter two are fixed, implementations should
have no problems figuring out the size of the PAD tag beforehand if that
is necessary. I do however understand that it can be nice to have an
"add_padding" function in a Roughtime implementation, which abstracts
away the details. I have such a function in my Python implementation,
where each tag is represented by a RoughtimeTag object in a sorted list.
The list can then be transformed into the Roughtime wire format at any
time. My C implementation, in comparison, is much simpler and creates
all tags first and then adds them to a message in hard-coded order.

On 2021-09-21 06:09, JP Sugarbroad wrote:
> Perhaps a GREASE-type tag space would be beneficial?

Section 6.1. of the current draft says "Tags other than NONC and VER
SHOULD be ignored by the server." There should probably be similar text
for the client, possibly along with text in Section 8. that the server
MAY send undefined tags along with otherwise valid responses.

On 2021-09-21 06:26, JP Sugarbroad wrote:
> I notice that DTAI and DUT1 are in milliseconds, while everything else
> is in microseconds. Is the extra range of a millisecond value needed?

I was the one to suggest using milliseconds, but I can't remember any
specific reason for that. Changing DTAI and DUT1 to microseconds gives
them a range of +/- 2147 seconds. That should be enough. In any case, we
won't be around if and when that becomes a problem.

On 2021-09-21 06:47, Watson Ladd wrote:
> DUT1 is only available in 10^-1s precision. DTAI is always whole
> seconds. We could probably fix that to be seconds.

The accuracy of DUT1 as specified by IERS Bulletin C is 0.1 seconds.
However, the IERS also provides higher accuracy DUT1 values in its daily
earth orientation parameters. For example, the predicted value for today
(September 21) is -0.1094794. Bulletin C currently says -0.1 seconds. We
may or may not want to clarify the draft in this regard.

Kind regards,