Re: [Ntp] Going forward with NTP - v5, v4 and approach

[Doug Arnold <[e-mail]>]

Excellent question.

I expect the process to work something like this:

  1.  Somewhat complete draft of ntpv5
  2.  First implementations tested with each other
  3.  Tweak first implementations to work well together
  4.  Refine draft to reflect any changes or clarifications that were needed for interoperability
  5.  Publish

What do others think?

Doug

From: ntp <[e-mail]> on behalf of kristof.teichel=[e-mail] <kristof.teichel=[e-mail]>
Date: Thursday, August 18, 2022 at 7:10 AM
To: NTP WG <[e-mail]>
Subject: [Ntp] Going forward with NTP - v5, v4 and approach
Everyone,

a bunch of the discussion that has occured recently with regards to draft-ietf-ntp-update-registries (and really to draft-mlichvar-ntp-ntpv5-04 as well) has touched on matters that were really a bit more foundational to the WG and its process.
Specifically, I'm talking about the following questions:

1) How do we approach NTPv5 (and further versions) regarding design?
One question raised is about the role of "...and working code" in relation to "rough consensus".
This seems closely related to the question of order: a) concept-specification-code versus b) concept-code-specification.

2) If there are conflicts between i) unwritten rule/tradition, ii) specification, and iii) an implementation (and iv), a different implementation!)... then what takes precedent?
I thought it obvious that a finished specification should be used as normative reference for what is "correct" over any implementation, but this seems to be a point of contention.
Same goes for my assumption that a memory of some once communicated intention (or an unwritten rule) should be disregarded if it is at odds with recent specifications, implementations, or both.

3) What is the/our stance on compatibility, and on versions overall?
Specifically, do we require/strongly desire backward compatibility?
What about forward compatibility?

4) Are mode 6 exchanges (any modes other than timing packets really) part of "the protocol"? Specifically, do they share a version number, or get their own?
Again, I would have assumed that obviously, one divides a protocol (with version number) into modes. I.e., there would be NTPv4, with one of its modes being NTPv4-mode6.
But one could also say that NTP-mode6 is kinda its own protocol, and then say something like "we are currently up to v4 for NTP-mode2/3, but only up to v2 for NTP-mode6"; I find this is asking for trouble, but one could do it. There is a strong point to be made then that this way, the mode would be its own protocol and should have its own specification.

5) What do we do for identifiers for experimental features?
Does anyone experimenting contact NTF for coordination?
Do they register values at IANA for each new experiment?
Do we register a range of values at IANA as "for experimental purposes", and then you use those until experiments are complete and potentially register different new values at IANA afterwards?


It seems a bit ridiculous, but I do at this point believe we are too open to goalpost-shifting without formal rough consensus on these points regarding our own process.
What can we do to clear them up, please?
Did I forget anything important in the same vein?



Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB)
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        [phone]
E-Mail:   [e-mail]
__________________________________________