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

Marcus Dansarie <marcus@dansarie.se> Fri, 14 February 2020 23:13 UTC

Return-Path: <marcus.dansarie.nilsson@gmail.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 9C4AB1201CE for <ntp@ietfa.amsl.com>; Fri, 14 Feb 2020 15:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.947
X-Spam-Level:
X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RISK_FREE=0.453, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aUNvHAZmTlWp for <ntp@ietfa.amsl.com>; Fri, 14 Feb 2020 15:12:57 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21DA120013 for <ntp@ietf.org>; Fri, 14 Feb 2020 15:12:56 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id f24so7844791lfh.3 for <ntp@ietf.org>; Fri, 14 Feb 2020 15:12:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:autocrypt:message-id:date:user-agent :mime-version; bh=pByj69FkWJ80AfjBBpx3krsey3uNlPHZh7SWuyt9GWs=; b=qXnu1YamBMscoBzrtw+KTUC9gMPzu2yFFL58LL5Cv8EnRS9BlcjmiVUEfCAqCdr7Rr 51xJgER5tbhO5TDGW5ADWDvgEl/je1KRxNV3pVtvUGTK+L82O9NPB1zrQuQ9gZZPYhFK haFaMXvQcpAiYaUImf/5wolDCeNYbzLLRN95q0Jxt+erC8HcDG1Vuqirn3CUprJjyXDA lVkDv48QPjaGn7Q0bT6mGerOGZnDdo8CvPzN82AaJfdsvDDQXIvhwfjm0eTg9V93QsYB 0fWq63ILnoNtipkELvKRZ8LdfTEqOV2V4V9rrsvjCbdZop1Ok0zvI6pk3DRsk5mviTxp tyew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:autocrypt:message-id:date :user-agent:mime-version; bh=pByj69FkWJ80AfjBBpx3krsey3uNlPHZh7SWuyt9GWs=; b=Ag0HVFbGUL5yVeBun1YNtyq0ZfZqgxauqTUh5bZFR1k5cnfCawIh7MsiOXo+fZHS5U Ag18DDjXXRSu9xsWNSIRcPGzi93358Fcfd27lXPDGaxxraOhlAJhOoZdurJHffkNRLIP vPvx7p9T8N3hxRx7W2wBE4SaOj10fWGiYFmjcI5FnnwHFrznzHLr0geW1DJ88FzzrdDc nhYa6lsaRtqunN1tui/kc1SdpNW8azIygvMXrBFBgAlKOgGNX9jkdpRMjyYR8DJc9pX8 FGBh4Pq6wkc27e/dxFHNSRAodHm+V84Mcxb+Zr7LmOLd/ikrTOw8FZYKuGMabEcp/ZX6 a8VQ==
X-Gm-Message-State: APjAAAWjg8s9ArpU7mQcBlhjDUfqreRpN754+WPFPcux5eodCujc5X0J 7VANZ6nN5Ni6anChdLrXr0YaTV1KR+96WQ==
X-Google-Smtp-Source: APXvYqze0QjU7z9BwCDN5G6myAaUer0F8sSCc+ECEKOc3nwVe+5AU69znwp2CO1SsPfCJ6dqZKtwAw==
X-Received: by 2002:a19:9d0:: with SMTP id 199mr2771244lfj.110.1581721973272; Fri, 14 Feb 2020 15:12:53 -0800 (PST)
Received: from [192.108.201.10] ([192.108.201.10]) by smtp.gmail.com with ESMTPSA id t10sm4119720lji.61.2020.02.14.15.12.50 for <ntp@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Feb 2020 15:12:52 -0800 (PST)
Sender: Marcus Dansarie <marcus.dansarie.nilsson@gmail.com>
To: "ntp@ietf.org" <ntp@ietf.org>
From: Marcus Dansarie <marcus@dansarie.se>
Autocrypt: addr=marcus@dansarie.se; prefer-encrypt=mutual; keydata= mQINBFawEn4BEAC8YukDy8f3eczlE8WAcuctrjsNltPCLZDzcj3vBmiayXlXuPULOopqeuw4 +oaZqj4KqvdFBA1mzvwPll7IHePuwAoJYJr48IbIXc9MRjtLoFtd0KnhiVPUS8F2cmfzSJ8E FEv92sz6UT8/tlLEu6sNqr6/caYUivspuW5wf4f6nkSE+6rao9Nx9X03r289IPNBSZv+Y/Ym jWHDPpbT8WLUJZ+A8RsW/1oza609oAzqTkclmnRzip8wZZWNg3Q55P7onBmTIOrEz13My9r5 DWCMHyxXgFL1RJ9YW0t4yRkRm+HvOn3Vesk3m8CCGA6esHV0IPZmBOxJr3l+UQYuDiTgFufr WMpu5MvlyKGHS4fNd505DyyJY2G6eQLLrOq3nZy4qoZSL42TMxzYglexg+H6P/YsIIShk5Ch h/hNphXjrElDWhbGT5JiRWIivgSj/gq5QVBbDLR3b25n9PA0byGemfcEHLkii6EKyH7GW6v9 sgmvCmPfEfppYcOP2g9Jdt8RPitx0UBjoCzWAn0Py0NvlFDyz0FQhWDPig3yo1CG5ljb686v VBwcHJthczUV0rIyVzfmnikIb9ZjydHSX3fFwLz1IcIIX+INS58qA0SDqOoyP2WTYGZCDPVw GMMh+wMtAL2MICTr6vybFWB58m4PsI1j8Ri+AQiEkxyJauI2WQARAQABtCRNYXJjdXMgRGFu c2FyaWUgPG1hcmN1c0BkYW5zYXJpZS5zZT6JAlwEEwEIAEYCGwMCHgECF4ACGQEJCwkNCAwH CwoEBhUKCQgLAgUWAwIBABYhBBfkVFb0H62SH33Csy9j5/6tpPBjBQJeDONDBQkJQKdFAAoJ EC9j5/6tpPBj/xkP/jXvaCeWK9zrphIn1oFX+ssyrJUnpPR0boj0kFsI8NQSReHJ4camTawp 8mhIWa3VWjY3BiklYhQHzFO2e/4lc8tLKHzTL9bSMRQkbmx+S5ek8JnBy9s6dqx+gNgFmm0I zm8iJeLwI0bOXxyOJ0ZGUif0Kf4ks++5NZNe9ybVnWrhjY63GNfQgJqFCZ2zOb1ua9EkiLWO EvFizody2Br3GuP4WyUgEyXLBwYsEzWYzTLaATbid8pWeghAJI880LTt54EtmLpzDKKrZB4H 4CFxh6IogSZTXIXZUbM6XfjMUpMYCzv+F46Hit01QmJtWlIHfjSRbS9H6b//gpCsAjlaYw2m eBovyl0q4sE9mXYxdTqlk51umsvfewravYsfDpSHZ+7iw9dSoft8CGI8PBSUfp3YhVlBzTeX AjYeQJ+aGsGYvn6I0OT5U085m/PsLzvjjcmgMasoYsThYssRE6UQNxXa7OljRlsTRL8f67Ty 6W3fSV6YLcfMEn5/Z9M6/I9W+V9XiaLgVGht03x2GzyE7On0gk/cgapREotaYiDXTzW4njDQ 5pgi85vBOIKX4shmlJ7TNPWSDEAaZRkZGVHzyw+VY+0gdcI65NXofESOzIRdWAHLeOL2savo LCdNJcophzJG6gbpqF6AawdE6YfJf3lsV6Fgp7qUXt5sNWsWF9f3uQINBFawEqwBEAClJOj1 zOQTMRGzLK/08tEdwR4EwBDiWNci0JtjT59xtJdlGujuf/9wkt9hRIiALqt8U0vHwCzmxVTP Eueewv40WOraJzzDv6OBXJZMeF+IN1/CGrZcn8rLG9J1CyyVf+gCxUUXmpQDlE91iYMB4ifj dTTTizRnVYOQh54TV0yyiL2bn+ZdL8NYNpUbpoG2vppltt0NXv9ib9WPug9Q8Sx33CkkCj3F HJLHeHqo6AkFTpBdSn6/Ezs+ZHpuhNCHtrZyiJOi2YZ8EzpuxDwVjHLh8iXu0amlXSGP5wA7 MpNEtomhGw3bUr3aBcenfS4u/RE3V/y+vXae33LtVmaH7sli0SmrP8iUxkks2qjtS6W2a/qF xlHK/FXBChNIG0uRROvDlIudg6UHzQlK4mBdraGz4etfDpsNAX0x5ssxBTaFrJlZz935GPLR sg4o5f+FYcQrIZGisfCmiH8rdF1bkz450/OyfzS7lTCoxeizOnlamVwUCTfrWah/l8BXgP/i Y6KlbGpfr7aVYvA5e7fPe7uRqzPsxq7pL72r3p/TkNuPtJ7cbShN99p7v/v38STSJ4jbzy2W LMBFw5dJI73XtSGU2g/viZgVfl4Tro4XeYMF/FmRDiYcd+GpuDoB+g+NJYpGRGnr4+GgWl9U YCnN1TE9LSpvehvvKMvGqi0U1ENOUwARAQABiQRbBBgBCAAmAhsCFiEEF+RUVvQfrZIffcKz L2Pn/q2k8GMFAl4M41wFCQlApzACKcFdIAQZAQgABgUCVrASrAAKCRDBCAAOw+Eh5rtYD/wN eZOov+0rwhszfD+IY9fI4qFUjuiKWR06fJ60HV7cStkDW6WtrF+NkUAwH5G0yrA+izyI9wtR 4r5OW5ruPWTRbHxOmsLfRnqh4dKU6uCvtoL+LNzAMyPORiZkzomOaKAPdtiVgECVupLsApDl 4tI2hpMYKmeTVuessXa83oGOi8uQGK/M57Koz20KPfLltJBsCcOwofCUdbmaPOlN/DspOaIe LWzN7qb3pzAuUltBCvVI3VRgqvfh6JSiGyaSUfjghfbtz0uAlZ4wSfHX2+Iw+1/9mlElZjkC y6QgxCb1vMqGSw5u596aGVm7m2zVGLn4/xhpFNbxHUwWre/AAMtJR5ASK3cq2au1U2rOja3f rRfzMuBqTrQGb+OcCaesaOssd7t+RmDKfv0u40z6ls9Mzav+BCXzfOnb3HNAgJE5C/xApTsd xhn5BZoxHy8N2Pc0emWe6JI5UDPlKpuwH6JDKrLaoHhE7Gy2U6iinQcgI5IEEa8wmwoWfkjU 5phTbZVHJ+yTOeZWcbJtyFIX18fbzyrZWguo1EWHubv33KqbiJ6klpfg5chwKXWZIlLmbivp Dv0KRybk5GB+X83OpeAH9dKT3kvcu6midppjFzakSIiaoSJDS9jcqQYEiRG71lnD7QdCoqjb fHZh8HXGYSbenDzisWIRouGsimOyeSaX6QkQL2Pn/q2k8GMJbw//fuKz02SFeJBoJL0riuwa Rz7xhoCuJ6F5T9foj5DMs1Bi2aNxHM+y8s60MrP48HrTmzvoirSR5n7hZdESVoE8HXqKeXD6 EBZyEDWWnqYbMMhdYUS7xKiA8SHMhF8qnT2Yy8OLeuXQPmfJWZcGGivNbmjRoGTh1rbIZPL5 8y5F4uY7TsJwX0nW5mMIngdEmSqoXOINa3+DrjG5zcpoCqGDFGEZSw6B3ZokceOUmSXyO6lk d0tL5G3B0ipUh47RIa81wmJDXqoF0g5nVjO/2fB6wzw9uITHVaLJ6ayCcKWQkyFJABN4ZLaF udK5V4241JieYgmy5uzD5xfKwwqqmj/qbVP0Gmw1mujAnR4KBppdsfDKle4hp/NriVAngKDC UgZwXk75qwbGkS7luHCF1x7sIA1Z332sROCYzALuWi4NzmcCUkdjKoMxqbFabFDpswq8mELe o1aYsyrpkDLOai3/M8EHRFNwgkfyweU+Xe+4H2H/yXeLOa17ED2xNcDnK+SnvFq+Hvsuu9m6 FbwLaAyGKW3d/D4be49/7Cwyk4aHM+nB/ozAvfeLkxXdZYtIIf72UbAHc9oJMLOEY1UqkHJ7 +mOxez7UWqErXxbauX+bZ70u5ipOf5E3wxdo7+E1FRMXReUHCysV0qUqNK/wG/NDFNQxYRnF ubNo7v9TpsmWZ8i5Ag0EVrASywEQAMscigyDy6txQ/cUE8P+S9zMPNbsTSqa3iyj0SREswxm JsrUou+yOt/Y4UxGX+JLc/zjI1+frWE33CNmucYMtrZSrxgQDp+Wp8Ak7UNQlBtRIjdcPqmA EFzgG9OP7If7MJZMeWVd47ybIYUKohuTdFgwJSF80f+DGLLjIchyVZbvyZWSQKIAxfavmZr1 CNEVYXyrL752rLVB+KnQgJaFqHFPp6cO/Y20ViF9QsLRtlref1VrxtdPuILhEKMmmc+ZRsDh J0V8Mi5q8pWcYWrz+JiVRyA1ULAhg6C2ypj1cFNnQyN22XptXbz687bqZQxar5xyAAV4D6i/ 8q1kNgSsbDq+XkWuGjS9kmvLGM9kGARNhMFNguJSgSfqZExPAJhCZ4hVboTKFoRR10482rlO yj0Va0GbmpGqftjNodA4mjpBi52pNymUF+s6eTk13L9DOOJ8d0+2Qd6e4uTeNXJhNW6g2l7b 5dt/bbHMla7hgqRKUtTqQRR2JCpP3vF4sHWnXYdEcJSACarBcxbfdwZBnF9Nwv7GiNTEEg7O +8qwlj16LTB8oNWjOwAHiqg0xQlL8JTz2rkX0gUIW1Hy9A6b6UikViRbmpHXg0s7364Xtxji mkKD8DVnC5NJDiwZztqG2iW7kxJnfA+eAClKEh+niZo5NpjWNUfhjUXM5DNVHtchABEBAAGJ AjwEGAEIACYCGwwWIQQX5FRW9B+tkh99wrMvY+f+raTwYwUCXgzjXAUJCUCnEQAKCRAvY+f+ raTwY0TWEACnl4/g2QvX/bCMTSgAeeHaX3Fs2k0j+XoOe0uwyPRxWzwtvAbipW7fRXdAru1v 4qJkoGQrZpXSKDQL1Ij5x7XM/SB5FaXjMspXZwB0Vh1kuTsdbAXuJhC8kIOsVBrnBOUtbYnY tjJT7yvOy1w1N3PaE9+/oW5DbiODd5LC3ZSG7hzFgYAfg0lm9DX2imPs6wnroWT4AN+Evvjk FC39HMrgavEWjgG2s5VvR15NWtNf/+8BPtMtMACzCeDKMBC+zYsoe0nksCas+XzUihERW2a6 vjCkzb6jVs5+QwapnskrKNw9CG7QTEcPsNXH7w798Q0/hFkAy6c1goH+YBMEmy/TtlXq0lMv TNzvB70Gjot9vc6FdQEeQW4BeEJ4E0Ii/aKV8PITTe45mO0YFyQooW7go1cIkY9Ue7/3ggr6 FXGDjFqNeZaf0S6XficHXHsmKYnObOsuFUfVpBZbhtiahR99VHMbiV+UjdUY3X5+Td5p/VIA sFbHFW7M157wHDJQDKad1NrvWjq5if/cpiKC1VYGLP595jlZUu99JmtwqlEEru6gh0Z94Iv3 8kAcSCf4M9jwwoTXKcHYXHezaFgl8q4op2C0dLWoJihgjXLYHYiQPNiRtkHPOPocDJtu3T1U foURyeSY4YcBgderqZHZgygBpdU0Arc9C5wWy1t9WofUIg==
Message-ID: <a4d11bbf-c8eb-d478-0143-f566c10faa88@dansarie.se>
Date: Sat, 15 Feb 2020 00:12:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="20BWXEWO5GJ0hGGsT34SmTY6STRB36bob"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/4ZY0wIUYtG1tgYR_bgl-HfbWWq8>
Subject: [Ntp] Suggested improvements to the Roughtime draft (draft-ietf-ntp-roughtime-00)
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: Fri, 14 Feb 2020 23:13:01 -0000

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.
(https://github.com/aanchal4/draft-roughtime)

For the impatient, I make the following suggestions in this email:
* Defining a Roughtime packet format with a header containing a magic
number and message length.
* More detailed specification of server and client behavior in the TCP
transport mode.
* Removal of the padding requirement in TCP transport mode.
* Explicitly allowing multiple requests in TCP transport mode.
* Adding the DUT1 and DTAI tags for transfer of offsets between UTC and
UT1, and UTC and TAI.
* Adding the LEAP tag to transfer information on future and past leap
second events.
* Adding a VER tag to indicate supported versions.
* Fixing a couple of minor nits.
* Revisited discussion on the timestamp format.

First of all, the words "packet" and "message" are used interchangeably
throughout the draft to refer to Roughtime messages. This might cause
confusion as "packet" is also used in different meanings in the same
document. I suggest that we use the term "packet" only for the contents
of an entire request or response. We should probably also consider
renaming Roughtime "messages" to "records" which carries less risk of
confusion. In my opinion, "record" is also a more fitting name.

The following occurrences of "packet" should be changed to "message":

The first sentence of Section 5.1.3 should read: "Tags are used to
identify values in Roughtime messages."

Section 5.2, near the end of the second paragraph: "[...] with the
exception of the last value which ends at the end of the message."

Section 6.2, in the paragraph that begins with "The RADI tag value", the
last word should be removed so that the sentence ends with "at the time
they compose the response."

(I realize that I may be the culprit behind these uses of "packet",
since I contributed a lot of text to an earlier draft.)



When I started trying to implement the Roughtime TCP mode, I found the
current draft to be vague. The uint32 length prefix is also a bit of a
kludge and I believe the TCP and UDP formats should be identical as far
as possible. Therefore, I suggest changing the text in Section 6 to:

"As described in Section 3, clients initiate time synchronization by
sending requests containing a nonce to servers who send signed time
responses in return. Roughtime packets can be sent between clients and
servers either as UDP datagrams or via TCP streams. Servers SHOULD
support the UDP transport mode, while TCP transport is OPTIONAL.

A Roughtime packet MUST be formatted according to Figure 2 and as
described here. The first field is a uint64 with the value
0x4d49544847554f52 ("ROUGHTIM" in ASCII). The second field is a uint32
and contains the length of the third field. The third and last field
contains a Roughtime message as specified in Section 5 and Section 6.1
or 6.2.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  0x4d49544847554f52 (uint32)                  |
   |                        ("ROUGHTIM")                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Message length (uint32)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                      Roughtime message                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: Roughtime Packet Format


Roughtime request and response packets MUST be transmitted in a single
datagram when the UDP transport mode is used. Setting the packet's don't
fragment bit [RFC791] is OPTIONAL in IPv4 networks.

Multiple requests and responses can be exchanged over an established TCP
connection. Clients MAY send multiple requests at once and servers MAY
send responses out of order. The connection SHOULD be closed by the
client when it has no more requests to send and has received all
expected responses. Either side SHOULD close the connection in response
to synchronization, format, implementation-defined timeouts, or other
errors."



Since there is no risk of amplification attacks in the TCP transport
mode, I suggest changing the text in Section 6.1 to

"A request is a Roughtime message with the tag NONC. The value of the
NONC tag is a 64 byte nonce. It SHOULD be generated by hashing a
previous Roughtime response message together with a blind as described
in Section 8.  If no previous responses are available to the client, the
nonce SHOULD be generated at random.

In the UDP transport mode, the size of a request message SHOULD be at
least 1024 bytes, responding to shorter requests is OPTIONAL for
servers, and servers MUST NOT send responses larger than the requests
they are replying to. To attain the minimum request size, clients SHOULD
add the PAD tag to the message. Its value SHOULD be all zeros.

The PAD tag SHOULD NOT be used in the TCP transport mode."




There may be cases where a Roughtime client wishes to send multiple
requests at the same time. Examples of this include proxies that perform
TCP to UDP connection bridging and clients that need to timestamp a
large number of hash values, e.g. for audit purposes. There is currently
no easy way of pairing received responses with their corresponding
requests. One way to facilitate this is for servers to include the NONC
tag in their responses.

Section 6.2 should also be updated to use RFC 2119 requirements language.

I suggest changing the beginning of the first paragraph to:

"A response MUST contain the tags SREP, SIG, CERT, INDX, and PATH as
described in this section. It SHOULD contain a NONC tag identical to the
one in the client's request."



ITU-R TF.460-6 recommends "that standard-frequency and time-signal
emissions, and other time-signal emissions intended for scientific
applications (with the possible exception of those dedicated to special
systems) should contain information on UT1 - UTC and TAI - UTC". To
satisfy this, I suggest adding support for the tags DUT1 and DTAI as
follows:

The first paragraph of Section 6.2 (in addition to the changes suggested
above) is appended with "Furthermore, the server MAY include the tags
DUT1 and DTAI in its response."

A description of those tags is then added to the end of Section 6.2:

"The DUT1 tag value is an int32 indicating the predicted difference
between UT1 and UTC (UT1 - UTC) in milliseconds as given by the
International Earth Rotation and Reference Systems Service (IERS).

The DTAI tag value is an int32 indicating the current difference between
International Atomic Time (TAI) and UTC (TAI - UTC) in milliseconds as
published in the International Bureau of Weights and Measures' (BIPM)
Circular T."

A new section defining the int32 data type should then be added after 5.1.2:

"A int32 is a 32 bit signed integer in signed magnitude representation
with the sign bit in the most significant bit. It is serialized with the
least significant byte first. The negative zero value (0x80000000) MUST
NOT be used."

The list of Roughtime tags in Section 13.2 and the terms and
abbreviations in Appendix A should also be updated accordingly.



Roughtime currently has no method for indicating future (or past) leap
seconds. It would be good if the protocol could warn about an upcoming
leap second event. I have also seen requests on this list for a method
to transfer leap second history information. For those reasons, I
propose that the LEAP tag is be added to the draft. It would be added
(along with DUT1 and DTAI) to the list of tags in Section 6.2 that a
server MAY include in its response. The following description could then
be added to the same section:

"The LEAP tag contains zero or more int32 values. Each value represents
the MJD of a past or future leap second event. Positive values represent
the addition of a second at the indicated date and negative values
represent the removal of a second at the indicated (negative) date. The
first item in the list MUST be the last (past or future) leap second
event that the server knows about. The leap second events MUST be sorted
in reverse chronological order. A leap tag with zero int32 values
indicates that the server does not hold any updated leap second
information."

The LEAP tag uses the new int32 type defined above. The list of
Roughtime tags in Section 13.2 should be updated to include the new LEAP
tag.



The previous drafts have made changes that make them incompatible with
each other. There is currently no way for either client or server to
indicate which version of the Roughtime protocol they are using. To
rectify this, I propose adding a VER tag to the protocol by making the
following additions to Sections 6, 6.1, and 6.2.

Section 6:

"All requests and responses MUST contain the VER tag. It contains a list
of one or more uint32 version numbers. The version of Roughtime
specified by this memo has version number 1.

For testing drafts of this memo, a version number of 0x80000000 plus the
draft number is used."

In Section 6.1, the following should be added as the penultimate paragraph:

"The VER tag MUST include at least one Roughtime version number
supported by the client. The client MUST ensure that the version numbers
and tags included in the request are not incompatible with each other or
the package contents."

In Section 6.2 the following changes should be made:

The VER tag is added to the list of required tags in the first sentence.

The following paragraph is added where suitable:

"The VER tag MUST include exactly one version number which indicates the
Roughtime version used for the response packet. How the server should
handle situations where it does not support any of the versions in the
request is currently unspecified."

A request to IANA for a Roughtime Version Number Registry should be
added to Section 13 and include a reserved space and a space for private
use. The list of Roughtime tags in Section 13.2 should also be updated
to include the new VER tag.



I have also found a couple of minor nits in the current draft and have
already submitted a pull request on Github to fix them. It was recently
accepted there by Watson Ladd.

* The title of Section 7 should read "Integration into NTP".

* The IANA request in Section 13.1 should be for both TCP and UDP as
transport protocols.

* The references section should contain a reference to RFC 793.



Another thing that needs to be addressed at some point is specifying the
JSON formats for exchanging information about server addresses and
suspected malfeasance.



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.



Kind regards,
Marcus Dansarie