[Ntp] Antw: [EXT] Re: The bump, or why NTP v5 must specify impulse response

>>> Philip Prindeville <philipp@redfish-solutions.com> schrieb am 21.04.2020
um
19:56 in Nachricht
<31673_1587492815_5E9F37CE_31673_735_1_2A6E880D-C467-4AC5-A8C2-F3C61B323A53@redf
sh-solutions.com>:

> 
>> On Apr 17, 2020, at 4:48 AM, Harlan Stenn <stenn@nwtime.org> wrote:
>> 
>> [snip]
>> 
>> More to the point, NTPv4 and all of its predecessors specified:
>> 
>> - the packet format
>> - the algorithms
>> - a set of behavioral limits and specifications
>> 
>> This means others were allowed to write specifications (regulations)
>> assuming and/or relying on "NTP" - the packet format, algorithms, and
>> behavior.
>> 
>> Removing or separating the algorithmic and behavioral specifications
>> from the NTP specification at best cost-shifts that discussion
>> elsewhere, and I submit it does this to groups that are likely
>> completely unaware that they can no longer rely on behavior that they
>> had no idea they previously relied on.
>> 
>> Are you planning to just do a protocol spec and "do the algorithms and
>> behavior spec later", or worse yet, let others do that if they think
>> it's important?
> 
> 
> Not to throw gasoline on the fire, but Postel told me decades ago, “don’t 
> confuse protocol and policy” (he was [ahem] encouraging me to drop 3 
> paragraphs from the draft of RFC 1048).  It was good advice then and it 
> holds.
> 
> Algorithms are, in essence, a “policy” for disciplining a clock.
> 
> A compromise might be to define requirements for the protocol 
> parametrically, in terms of drift, jitter, etc. while not defining the 
> algorithms to do that.

What speaks against that IMHO is correctness assumptions: If everybody can
define his own algorithms, but subsequent clients have to use those numbers for
their own correctness calculations, how can a client have any guarantee that
the time is within the bounds the packets (I'm not using the word "protocol")
claim? Even with the current NTP implementation it's quite a challenge to
assure that the time displayed is the actual time (the NTP performance numbers
may look nice, but still the time can be wrong).

> 
> This opens the field up to more active research in ways to improve the 
> protocol and the use of clocks without tying anyone’s hands.
> 
> The protocol could provide a “reference algorithm” that’s used as a baseline

> and as an example of a certain performance “envelope” under well-defined 
> circumstances.
> 
> Given how long NTPv4 has been around (for both right and wrong reasons), 
> it’s reasonable to expect NTPv5 to live at least half as long.  A lot of 
> technology can potentially emerge during that time and we should have the 
> flexibility to incorporate it as it develops.
> 
> Look how far we’ve come since Cesium ovens as reference clocks.
> 
> -Philip
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 