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

Danny Mayer <> Wed, 22 September 2021 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFCF83A25B3 for <>; Wed, 22 Sep 2021 08:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 31bWZjz0UbNX for <>; Wed, 22 Sep 2021 08:00:12 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:205::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 652F13A25A1 for <>; Wed, 22 Sep 2021 08:00:01 -0700 (PDT)
Received: from newusers-MBP.fios-router.home ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4HF1fy114YzMNQY; Wed, 22 Sep 2021 14:59:54 +0000 (UTC)
To: Marcus Dansarie <>,
Cc: JP Sugarbroad <>
References: <> <> <> <> <> <>
From: Danny Mayer <>
Message-ID: <>
Date: Wed, 22 Sep 2021 10:59:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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: Wed, 22 Sep 2021 15:00:23 -0000

On 9/21/21 3:24 PM, Marcus Dansarie wrote:
> 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:

It would make more sense to make all of the tags 4 ascii characters and 
be done with it. I also don't understand the need for PAD and that the 
message has to be at least 1024 bytes in length. The length of the 
message is included in the packet so such a requirement is unnecessary.