Subject: [Ntp] draft-gruessing-ntp-ntpv5-requirements - contributing

From: [email-masked]
Date: Tue, 8 Mar 2022 12:56:10 +0100

Hello all,

I have semi-recently spoken with my superiors at PTB, and it was agreed that, after finishing some previous commitments, I should spend a considerable part of my time and effort contributing to the NTPv5 update.

Those previous commitments are now all over or in the process of ending, thus I'm ready to start contributing.

The first thing I'd like to take a harder look at is obviously James' requirements draft.

I have a few questions right off the bat.

1) Did we ever discuss the conceptual overall use of "MUST"/"SHOULD"/... normative language here?

This is a draft that is now normatively describing what another document ought to look like at a later time.

I was under the impression (from RFC2119) that these requirements levels were intended to denote how implementors of a specification had to act when realizing it into code.

It's not that I really mind it, and the sentiment is both clear and seems good to me; it just seems unusual.

2) One aspect that at least PTB would like to see considered is the question of (metrological) tracebility [i.e., "property of a measurement result whereby the result can be related to a reference through a documented unbroken chain of calibrations, each contributing to the measurement uncertainty"].

This was last brought up and talked about around the change of year 2020/21, with Dieter suggesting it should be treated somehow, and a general apparent consensus that it relates to the uncertainty-related fields of precision, root delay, and root dispersion).

Did we ever decide to drop the topic, or was it just not picked up (or seen as dealt with, in which case I'd disagree)?

Even if it might be a headache to deal with the definitions, the fact of the matter is that using NTP to synchronize a machine's clock closely "to UTC" is, after all, a metrological undertaking.

I do think it would make sense to at least discuss in an eventual NTPv5 RFC to what extent synchronization with NTP(v5) covers uncertainty and offers traceability.

3) I need a reminder: what is the current schedule for how we deal with the requirements draft (adopting as a WG document, further steps) as related to the development of a (perhaps Miroslav's) true NTPv5 specification draft?

@James, @Karen, @Dieter: If I want to get more involved with the requirements document, how can I best do that, seeing as it's currently an individual contribution?

Best regards,

Kristof

---

From: James <[email-masked]>
Date: Tue, 8 Mar 2022 13:49:47 +0100

Hi Kristof,
Great to hear you're able to participate in this work.
My responses inline.

> On 8 Mar 2022, at 12:56, [email-masked] wrote:
> 

As I said recently on list [1], I have been deliberate in my use of normative and non-normative language, knowing that it's presently an individual draft, and that they will be subject of discussion and debate if it's adopted and details are worked out. I consider myself flexible on many of the requirements, provided there is clear consensus from the wider working group.

> I do think it would make sense to at least discuss in an eventual NTPv5 RFC to what extent synchronization with NTP(v5) covers uncertainty and offers traceability.

I'm unsure if there's been any notable discussion of this, but that isn't to say it is unimportant. From a different, maybe related angle regarding traceability I've been considering separately thinking [2] how to propagate source synchronisation authentication - to give a specific example, could NTP clients benefit from having assertions and information that Galileo OSNMA messages validated or failed, and combined with the protocols' own authentication methods have greater trust against adversary or error that would lead to invalid timestamps or information being transmitted. Is this something along what you've been considering, or are you looking at something else?

> @James, @Karen, @Dieter: If I want to get more involved with the requirements document, how can I best do that, seeing as it's currently an individual contribution?

Regardless if the WG adopts the document, it's likely that it will remain hosted in my Github repo [3] - you're more than welcome to contribute to it.

- J

1: https://mailarchive.ietf.org/arch/msg/ntp/a92nDgWaF5C-PXJhYPO5fkm1B2o/
2: https://fiestajetsam.github.io/2022/02/04/future-time-protocol-security.html
3: https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements