Re: [Ntp] Suggested improvements to the Roughtime draft (draft-ietf-ntp-roughtime-00)

Watson Ladd <> Sat, 15 February 2020 01:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62C151201EA for <>; Fri, 14 Feb 2020 17:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bWqq7GrKhFZK for <>; Fri, 14 Feb 2020 17:12:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 536611201DE for <>; Fri, 14 Feb 2020 17:12:12 -0800 (PST)
Received: by with SMTP id d11so11024471qko.8 for <>; Fri, 14 Feb 2020 17:12:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6k2RjkNklWBu4toYOSR0nVBfoOhonFyy1bSbCbtCMr0=; b=FykfH+Ulcjljfp0qxR34tqVDG62UpkwazC0KAc1GH0mD4Dea0iZG506l1bX/nuikTJ g4ZQzvXzARKzDeZ3Ml/9vBJNWIuCxwS85wPar8vI/FaZwqF3uVDvz7fGtoK+gYJeJduv Bigbmpsp1ELo7mGJPe45SrncFDS3fX6M5AIaY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6k2RjkNklWBu4toYOSR0nVBfoOhonFyy1bSbCbtCMr0=; b=WvnCBEJJ7LC/jO+3aPEAZNrcoRKPX1EX5/Fd0EceAW3b0WKPTbwUfAxW/G999CirhH b7AZPxkfSuGF8XhZZyFV+EchgWsaGnrT4i0gWhnUEmS9xIEAjHHv8esE9Ruvn+ovbpNh tAL1J7aHijd9AjGWRCDRHRRfOK5WAI8LMJ1y4ZmG/ArKyGBGX+vmLXdY8QPxctfkYdOh 4E9LKwjILNOCF0PtzL4UEWM7srIxdy2zp3VhIUy6/UcmK/WY0w/42UKaYr5lelE2X/mK xxLjIhXeb96Y1rG4T5eppDaBsh6lNpfrU7j2MkCegJWPtZ3W2Ln9gTHoHzUZCQrT3zUt gWYg==
X-Gm-Message-State: APjAAAUEE7JK3vvRHSIcL7iKceJcCet+PFb20UXcAlzVThsfPvCOAKnh 5iXprG22u113fT7CnVi5BL58sQmCu9Z9+9lwrHoXs9sIGGw=
X-Google-Smtp-Source: APXvYqwA+CfX4YWr7VrH2ywrK6Od1Caj5ROZifyPH4OsK22dTbwVg5WWN2yWNK1PoWd/LUr2RK8nnH6StHi29tI4m6g=
X-Received: by 2002:a37:9407:: with SMTP id w7mr5083881qkd.55.1581729131328; Fri, 14 Feb 2020 17:12:11 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Fri, 14 Feb 2020 17:12:00 -0800
Message-ID: <>
To: Marcus Dansarie <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000000124d3059e9303da"
Archived-At: <>
Subject: Re: [Ntp] Suggested improvements to the Roughtime draft (draft-ietf-ntp-roughtime-00)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Feb 2020 01:13:02 -0000

On Fri, Feb 14, 2020 at 3:13 PM Marcus Dansarie <> wrote:
> All,
> I finally found some time to go through the recent Roughtime draft. A
> number of issues, ideas, and suggestions follow below. I can submit any
> accepted suggestions as pull requests on Github.
> (

Thank you very much for doing this! I consider most of your suggestions
excellent ideas, but perhaps others have additional input they wish to give.

Some fields especially DUT1 and DUTC might not be available over NTP, PTP,
or NEMA. That makes it a bit tricky to get out of a GNSS unit, even if it
available from the satellite. Since these are optional fields I'm not that
concerned, but it would be a shame if no one could use it. I would make
NONC echoing a MUST: it's trivial for servers to do, has no downsides I can

We may have to refine the notion of malfeasance to cover additional data
such as leap seconds, but that does seem a bit tricky as not all leap
second dissemination mechanisms function the same way or have the same view
I have been working on providing formulas for MJD conversion, so the
textual changes you have suggested would be mostly complementary.

> Finally, I have revisited Peter Löthbergs suggestion regarding the
> timestamp format. The current timestamp format specified in Section
> 5.1.4 doesn't use the full available resolution. His suggestion was that
> we use the full 40 bits of resolution to represent fractions (2^-40) of
> a day. The value is multiplied by 86400 * 2^-40 to get the number of
> seconds since midnight. Using information from the LEAP tag suggested
> above, clients will use 86401 * 2^-40 or 86399 * 2^-40 on leap second
> days. An added advantage of this is that clients that wish to leap smear
> can do so simply by always using the standard multiplier. I'd like to
> hear your opinions on this.

I'm not sure I entirely understand the proposal: it seems that the idea is
to use the 5 fraction of day bytes to represent 2^-40 of the current day,
where the length of the current day in seconds is determined by the LEAP
field applicable to the day in question. My first concern is with the
intervals: if specified as additions to this timescale they change length
with respect to the SI second depending on what day it is. If we don't then
interval arithmetic becomes a bit tricky, as part of the interval is
converted with one number, and part with another number. Comparing packets
where there is disagreement over whether or not a leapsecond happened now
seems a bit tricky.

At a more practical level there is a problem with leap second indications
arriving later in the day. Not all leap dissemination mechanisms work ahead
of time: some only work the same day such as NTP. A server that learns that
there that there is a positive leapsecond in the middle of the day will
adjust the number of seconds it thinks are in the day, so the timestamps
here cannot be directly compared without knowing the leap state the server
is applying, and they have to be converted to some other scale to compare
numerically. That makes me hesitate to endorse this idea but perhaps when I
see formulas I'll be happier with it.

Watson Ladd