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

[Marcus Dansarie <[e-mail]>]

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:
https://mailarchive.ietf.org/arch/msg/ntp/BSYmaFGoEYHNECg2Mc2qgjzQZh4/

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,
Marcus